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ABSTRACT 


This  thesis  focuses  on  the  completion  and  hardware  testing  of  a  fault  tolerant 
computer  system  utilizing  Triple  Modular  Redundancy  (TMR).  Due  to  the  radiation 
environment  in  space,  electronics  in  space  applications  must  be  designed  to  accommodate 
single  event  phenomena.  While  radiation  hardened  processors  are  available,  they  offer 
lower  performance  and  higher  cost  than  commercial  off  the  shelf  processors.  In  order  to 
utilize  non-hardened  devices,  a  fault  tolerance  scheme  such  as  TMR  may  be  implemented 
to  increase  reliability  in  a  radiation  environment.  The  design  that  was  completed  in  this 
effort  is  one  such  implementation. 

The  completion  of  the  hardware  design  consisted  of  programming  logic  devices, 
implementing  hardware  design  corrections,  and  the  design  of  an  overall  system  controller. 
The  testing  effort  included  basic  power  and  ground  verification  checks  to  programming, 
executing,  and  evaluating  programs  in  read  only  memory.  During  this  phase,  additional 
design  changes  were  implemented  to  correct  design  flaws. 

This  thesis  also  evaluated  the  preliminary  design  changes  required  for  a  space 
implementation  of  this  TMR  design.  This  included  design  changes  due  to  size,  power, 
and  weight  restrictions.  Additionally,  a  detailed  analysis  of  component  survivability  was 
performed  based  on  past  radiation  testing. 
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EXECUTIVE  SUMMARY 


Increased  demands  on  satellite  performance  and  a  declining  budget  have  forced 
engineers  to  search  for  cheaper  and  faster  products.  Past  satellite  designs  were  restricted 
to  the  utilization  of  radiation-hardened  devices,  today  though  the  use  of  Commercial  off 
the  Shelf  (COTS)  devices  is  increasing.  In  order  to  utilize  COTS  devices  in  space 
though,  the  engineer  must  employ  a  method  of  increasing  the  reliability  and  redundancy 
of  a  system  such  as  Triple  Modular  Redundancy. 

A  Triple  Modular  Redundancy  design  was  previously  fabricated  to  prove  the 
implementation  of  this  concept.  The  objectives  of  this  research  are  the  completion  of  the 
design  and  verification  of  proper  operation.  The  research  began  with  the  completion  and 
testing  of  the  design  files  previously  written  for  the  programmable  logic  devices  utilizing 
WINCUPL  and  Xilinx  design  software.  During  this  phase,  a  design  file  for  a  PLD  was 
modified  to  correct  for  an  error.  These  design  files  were  ultimately  burned  into  the 
programmable  logic  devices. 

The  last  step  in  completing  the  TMR  board  was  the  design  and  programming  of 
the  system  controller  FPGA.  This  FPGA  is  responsible  for  data  input  and  output,  board 
setup,  and  FIFO  data  collection.  This  design  was  accomplished  utilizing  the  Xilinx 
foundation  HDL  and  state  machine  tool. 

With  the  completion  of  the  programming  and  design  phases,  a  thorough  review  of 
the  design  revealed  a  problem  with  the  Field  Programmable  Array  devices.  The  devices 
utilized  in  the  design  required  3.3  Voltage,  while  the  board  was  designed  with  a  5V  bus. 


xv 


The  addition  of  a  voltage  regulator  into  the  board  to  provide  the  necessary  voltage  for  the 
FPGAs  was  the  final  solution  to  this  difficulty. 

Upon  completion  of  the  system  design  corrections,  initial  testing  of  the  design  for 
proper  operation  consisted  of  basic  power  and  ground  verification  checks  to  executing 
programs  in  read  only  memory.  Numerous  programs  were  written,  compiled,  linked,  split 
and  burned  into  ROM.  A  digital  logic  analyzer  was  used  to  capture  program  execution  to 
verify  proper  read  and  write  cycles  to  RAM  and  ROM.  The  captured  data  provided 
waveforms  and  data  lists,  which  confirmed  correct  timing.  The  next  program  transmitted 
serial  data  from  the  16550  UART  to  a  PC.  Initially  difficulties  in  obtaining  output  led  to 
the  discovery  of  an  incorrect  device.  After  obtaining  the  new  device,  the  correct  output 
baud  rate  and  data  waveforms  were  present  on  the  UART.  The  final  design  program 
captured  transmitted  data  from  the  PC,  added  32,  and  transmitted  this  data  to  the  PC. 

This  work  also  focused  on  the  preliminary  design  changes  necessary  for  space 
implementation  of  the  TMR  design.  This  included  design  changes  due  to  size,  power, 
and  weight  restrictions.  It  also  included  a  detailed  analysis  of  component  survivability 
based  on  past  radiation  testing. 

The  effort  in  this  work  completed  the  design  and  programming  of  the  TMR  logic 
devices  and  microprocessors.  The  waveforms  and  captured  data  supported  the  design 
implementation  and  predicted  timing  waveforms.  The  benefit  of  work  on  this  design  is 
the  utilization  of  higher  speed  COTS  microprocessors  in  space  applications  and  a  testbed 
for  investigating  software  fault  tolerant  methods. 
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I.  INTRODUCTION 


Increasing  the  radiation  tolerance  of  a  spacecraft  against  the  environment  of  space 
is  the  most  important  aspect  in  making  it  more  survivable.  Since  the  end  of  the  1980s, 
the  Defense  budget  has  seen  a  dramatic  decrease  in  funding.  This  has  in  turn  affected  the 
research  and  development  of  radiation  hardened  devices  by  the  commercial  sector. 
Additionally,  commercial  companies  such  as  Intel  are  reluctant  to  switch  their  foundries 
from  production  of  normal  microelectronics  devices  to  radiation-hardened  devices  as  a 
result  of  the  loss  in  revenue.  The  result  of  this  is  a  very  limited  availability  of  hardened 
devices  at  a  high  cost.  Spacecraft  Engineers  working  with  lower  budgets  are  therefore 
forced  to  look  for  alternative  cheaper,  faster  and  better  performing  methods  of  increasing 
the  survivability  of  the  Spacecraft.  One  alternative  is  the  use  of  commercial-off-the-shelf 
(COTS)  devices  in  place  of  radiation-hardened  devices.  COTS  devices  present  spacecraft 
engineers  with  shorter  design-to-launch  times,  lower  parts  costs,  orders  of  magnitude 
better  performance,  and  a  wider  range  of  available  software  than  radiation  hardened 
(radhard)  devices.  The  major  drawback  to  utilizing  COTS  devices  in  designing  a 
spacecraft  is  their  increased  susceptibility  to  the  effects  of  radiation,  both  total  dose  and 
single  event  upsets  (SEUs)  and  system  design  techniques  to  protect  them  from  this 
radiation  such  as  increased  shielding. 

This  thesis  is  a  continuation  of  an  ongoing  multi-thesis  project  initiated  by  LT. 
Payne  [Ref.  1],  Capt.  David  Summers  [Ref.  2]  and  Capt.  Kim  Whitehouse  and  LT.  Susan 
Groening  [Ref.  3].  It  will  present  the  concluding  designs  and  testing  of  a  fault  tolerant 


1 


computer  evaluation  system  including  the  design  of  the  system  controller.  Additionally, 
it  will  also  present  the  necessary  changes  for  a  space  flight  ready  design. 

The  system  is  designed  to  perform  two  functions.  First,  it  can  act  as  a  software 
testbed  by  enabling  testing  of  fault  tolerant  software  in  the  presence  of  radiation  induced 
SEUs  in  a  test  chamber.  This  allows  testing  of  the  software  algorithms  in  the  environment 
they  were  designed  to  operate  enabling  detection  and  isolation  of  errors.  Additionally,  the 
design  can  be  used  as  a  combination  software  and  hardware  fault  tolerant  computer 
system.  This  is  accomplished  by  utilizing  the  fault  masking  ability  of  the  hardware  with 
fault  tolerant  software.  Both  of  these  concepts  will  be  discussed  further  in  the  body  of  the 
thesis. 

A.  THE  SPACE  ENVIRONMENT 

As  satellites  become  increasingly  complex  and  versatile,  the  amount  of  electronic 

equipment  in  them  grows.  Care  has  to  be  taken  to  protect  this  equipment  from  both 
temporary  and  permanent  damage  from  the  environment.  Designing  equipment  for  space 
requires  that  the  designers  know  the  working  environment.  Like  any  environment,  space 
dictates  the  characteristics  of  devices  intended  to  operate  there  and  imposes  requirements 
on  any  equipment  that  would  function  there.  This  environment  poses  a  risk  to  all  earth 
orbiting  satellites  and  missions  to  other  planets  in  the  form  of  electromagnetic  radiation 
from  the  sun:  not  only  visible  light,  but  the  entire  range  from  radio  to  gamma  rays.  In 
addition,  it  is  also  filled  with  the  corpuscular  radiation  of  the  sun,  the  solar  wind.  Some 
of  this  is  trapped  within  the  earth’s  magnetic  field  forming  the  intense  radiation  of  the 
Van  Allen  Belts.  [Ref.  1] 
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1.  Radiation 


Radiation  is  the  movement  of  energy  through  space  by  propagation  of  waves  or 
particles.  Most  of  the  radiation  in  space  near  Earth  comes  from  the  sun,  as  fusion  in  the 
sun  shoots  particles  through  space.  Around  the  planet’s  magnetic  field,  these  particles 
become  trapped  or  are  deflected  away  from  the  planet.  These  particles  pose  a  threat  to  the 
equipment  of  a  spacecraft  and  can  cause  damage  or  disruptions  in  microelectronic 
devices.  [Ref.  1] 

These  particles  are  either  ions  or  photons.  When  an  atom  is  hit  by  a  fast-moving 
particle,  an  electron  can  be  torn  off  producing  an  ion.  There  are  two  types  of  ions:  light 
and  heavy.  The  proton  or  light  ion  is  the  simplest  positive  ion  and  is  a  fundamental 
particle  with  low  mass.  The  heavy  ion  or  alpha  particle  is  produced  from  the  Helium 
atom.  The  helium  atom  contains  two  electrons,  two  protons,  and  neutrons.  When  the 
electrons  are  stripped  away,  the  atom  is  ionized  to  HE++,  which  is  known  as  an  alpha 
particle.  The  classifications  of  ions  as  heavy  or  light  is  dependent  on  the  atomic  number 
of  the  element.  All  ions  starting  with  the  element  Helium  are  classified  as  heavy  ion. 
Unlike  ions,  photons  have  neither  mass  nor  charge.  X-rays  are  an  example  of  photon 
radiation.  [Ref.  4] 

Multiple  sources  in  space  produce  these  radioactive  particles.  The  first  and  largest 
source  of  radiation  is  the  Sun,  which  produces  solar  flares  and  winds.  Solar  activity  of 
the  sun  varies  over  an  1 1-year  solar  cycle,  producing  a  variable  average  of  solar  particles. 
Though  the  solar  activity  is  predictable  on  a  macro  scale,  the  sun  still  produces  wide 
variations  in  radiation  intensity  on  a  day-to-day,  hour-to-hour  basis. 
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A  second  radiation  type  is  Galactic  Cosmic  Ray  or  GCR,  which  are  particles  that 
reach  near-earth  from  outside  of  the  solar  system.  The  cosmic  ray  consists  of  heavy  ions 
produced  by  such  events  as  exploding  stars. 

The  last  and  largest  contributor  to  a  spacecraft’s  total  dose  is  from  particles 
trapped  in  the  Earth’s  geomagnetic  field,  otherwise  known  as  the  Van  Allen  Belts.  The 
belts  are  a  fixed  hazard  to  spacecraft  and  are  distributed  nonuniformly  within  the 
magnetosphere.  Any  satellite  in  orbit  is  subject  to  effects  from  the  Van  Allen  Belts. 
[Ref.  5] 

With  this  in  mind,  two  factors  are  calculated  to  assist  in  determining  the 
survivability  of  the  spacecraft.  The  first  is  the  total  dosage,  the  total  amount  of  radiation 
the  spacecraft  will  be  exposed  to  during  its  lifetime.  The  second  is  the  dose  rate  effect, 
the  amount  of  radiation  the  spacecraft  is  exposed  to  at  a  particular  time.  As  the  spacecraft 
orbits,  radiation  passes  through  it  possibly  affecting  the  spacecraft  subsystems.  When  this 
radiation  interacts  with  microelectronic  devices,  it  can  cause  a  malfunction  known  as  a 
Single  Event  Phenomena,  or  SEP.  Single  event  phenomena  consist  of  three  different 
effects,  the  single  event  upset  (SEU),  single-event  latchup  (SEL)  and  the  single-event 
burnout  (SEB),  which  are  discussed  in  detail  in  the  following  section.  [Ref.  6] 

B.  SINGLE  EVENT  PHENOMENA  (SEP) 

SEPs  occur  when  a  high-energy  particle  passes  through  the  microelectronic  device 
and  deposits  enough  charge  to  cause  a  transistor  to  change  state.  In  most  cases,  the 
transistor  only  changes  state  long  enough  for  the  charge  to  be  absorbed  back  into  the 
system  and  then  resumes  its  original  state.  The  transistor’s  state  change  can  lead  to 
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latchup  in  parasitic  transistors,  high  current  state  in  a  power  transistor,  or  can  be  latched 
into  a  storage  element.  These  three  main  types  of  SEP  in  Complimentary  Metal  Oxide 
Semiconductors  (CMOS)  are  discussed  in  the  following  sections.  [Ref.  6] 

1.  Single  Event  Upset  (SEU) 

An  SEU  is  an  unpredicted  change  of  state  or  “bit-flip”  induced  by  an  energetic 
particle  such  as  a  proton  passing  through  a  device.  In  a  spacecraft  computer,  for  example, 
a  bit-flip  could  lead  to  a  random  change  in  critical  data  confusing  the  processor  to  the 
point  it  crashes.  In  microprocessors,  SEUs  are  typically  grouped  into  one  of  two  error 
types:  program  run  errors  and  data  errors.  Program  run  errors  are  errors  that  occur  in  the 
control  logic,  program  counter  (PC),  or  any  other  register  that  determines  the  state  of  the 
processor.  Data  errors  are  typically  confined  to  the  data  registers  and  cache.  These  two 
types  of  errors  are  not  necessarily  exclusive.  A  data  error  could  occur  in  a  register  that  is 
later  used  as  program  address.  When  the  microprocessor  reads  the  address  held  in  that 
register  it  is  in  the  wrong  location  and  begins  to  execute  incorrect  code.  [Ref.  6] 

2.  Single  Event  Latchup  (SEL) 

Integrated  circuits  are  made  by  combining  adjacent  p-type  and  n-type  regions  into 
transistors.  By  the  nature  of  the  process,  parasitic  transistors  are  formed  along  alternate 
paths  through  the  circuit.  These  parasitic  transistors  are  biased  off  by  the  circuit  design 
under  normal  circumstances.  Latchup  occurs  when  a  charge,  such  as  that  produced  by  a 
particle,  activates  one  of  these  parasitic  transistors,  which  forms  into  a  circuit  with  large 
positive  feedback.  This  creates  a  short  circuit  across  the  device,  with  two  possible 
outcomes.  The  first  is  the  current  drawn  through  the  parasitic  transistors  generates  more 
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heat  than  the  device  can  dissipate  and  destroys  it.  If  the  device  is  able  to  dissipate  the 
heat,  the  large  amount  of  current  drawn  through  the  parasitic  transistors  prevents  the 
circuit  from  working  correctly,  which  is  a  non-destructive  SEL.  The  normal  symptom  of 
a  non-destructive  SEL  is  of  a  hung  system,  which  requires  the  system  power  to  be  cycled 
before  proper  operation  is  restored.  [Ref.  6] 

3.  Single  Event  Burnout  (SEB) 

Single  Event  Burnout  is  another  condition  that  can  cause  device  destruction.  It  is 
caused  by  a  single  ion,  for  example  from  a  GCR,  which  induces  a  high  current  state  in  a 
MOSFET  destroying  the  circuit.  [Ref.  6] 

C.  COMMERCIAL-OFF-THE-SHELF  VS.  RADIATION  HARDENED 

DEVICES 

The  radiation  effects  discussed  in  the  previous  sections,  with  the  exception  of 
SEUs,  are  destructive  in  nature.  The  main  way  of  reducing  their  effects  is  by  utilizing 
radiation  hardened  (radhard)  devices  or  providing  shielding.  A  radhard  device  is  one  that 
is  specifically  designed  to  be  able  to  withstand  higher  amounts  of  radiation  than  standard 
commercial  parts. 

Determining  the  suitability  of  commercial-off-the-shelf  (COTS)  microprocessor 
for  space  applications  is  a  subject  of  ongoing  research.  There  are  multiple  reasons  for 
utilizing  a  COTS  product  within  such  a  harsh  environment  as  space.  This  section  will 
present  a  few  of  the  rationale  leading  to  the  use  of  COTS. 
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1.  Forward-looking  Technology 

As  touched  upon  earlier  in  the  introduction,  the  United  States  radiation  hardened 
market  is  rapidly  shrinking.  The  small  percentage  of  the  overall  market  that  requires 
radhard  components  puts  severe  economic  constraints  on  the  companies  that  produce 
these  devices.  The  number  of  companies  developing  and  marketing  radhard  devices  is 
rapidly  on  the  decline  and  the  remaining  companies  are  not  developing  new  chip  designs. 
For  these  reasons,  the  development  of  radhard  devices  is  lagging  behind  state  of  the  art 
technology  by  two  or  more  generations.  As  an  example,  a  spacecraft  launched  in  space  at 
present  would  have  at  best  the  equivalent  of  a  486  66  MHz  CPU  radiation  hardened 
microprocessor  compared  to  the  standard  home  computer  with  a  modern  700  MHz 
Pentium  El  processor.  This  entire  order  of  magnitude  difference  in  processor  capability 
makes  the  COTS  processor  especially  appealing.  [Ref.  7] 

2.  Faster  Design-to-Orbit  Time 

Parts  availability  is  crucial  in  maintaining  a  development  schedule.  The  limited 
availability  of  radhard  devices  offered  by  many  manufacturers  can  lead  to  a  delay  in 
production  schedule.  By  utilizing  COTS  devices,  the  production  flow  is  maintained.  The 
spacecraft  engineer  is  given  a  wider  selection  of  devices  to  utilize  from  multiple  vendors. 
Additionally,  the  utilization  of  COTS  allows  for  parts  interchangeability  in  case  of 
failure.  This  translates  to  less  non-value-added  time  in  the  development  schedule. 
Numerous  companies  are  conducting  radiation  testing  on  devices,  creating  a  growing 
database  of  devices  suitable  for  space  applications.  [Refs.  7  and  8] 
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3.  Reduced  Cost 


Low  demand  and  little  profit  exist  in  the  production  of  radhard  devices,  which  has 
led  to  many  manufactures  abandoning  their  production  of  radhard  devices  in  favor  of  the 
more  lucrative,  higher  volume  consumer  electronics.  The  limited  availability  of  these 
devices  then  leads  to  an  inflation  of  the  cost.  Part  cost  directly  impacts  the  cost  of  the 
product.  In  a  time  of  shrinking  budgets,  the  spacecraft  engineer  is  looking  for  a  cheaper 
suitable  product.  The  best  alternative  is  the  development  of  hardware  and  software  fault 
tolerant  designs  with  non-radhard  COTS.  [Ref.  7] 

D.  PURPOSE 

The  goal  of  this  research  is  the  testing  and  implementation  of  a  fault  tolerant 
computer  system  using  COTS  microprocessors  that  is  capable  of  operating  in  the 
presence  of  radiation  induced  SEUs.  This  thesis  specifically  concentrates  on  the 
programming  and  initial  testing  of  a  design  previously  fabricated  in  the  work  reported  in 
Reference  2. 

This  design  did  not  take  into  account  total  dose  radiation,  which  is  a  factor  that 
usually  limits  the  operational  lifetime  of  spacecraft  electronics.  This  factor  is  determined 
by  the  electrical  properties  of  solid-state  components  exposed  to  radiation  over  a  period 
of  time.  Ultimately  the  long  exposure  to  radiation  leads  to  changes  in  the  component 
parameters  outside  of  design  specifications  and  causes  the  circuit  to  cease  proper 
functioning.  This  factor  is  less  stringent  in  the  design  because  of  spacecraft  shielding, 
component  selection  and  survivability. 
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Successful  completion  of  this  project  will  lead  to  numerous  benefits  for  the  space 
community.  First,  the  adage  of  faster  better  cheaper  can  be  utilized  in  the  development  of 
spacecraft.  The  spacecraft  engineer  will  have  a  broader  choice  of  devices  and  software  to 
choose  from  at  a  reduced  cost.  The  spacecraft  design  will  no  longer  be  restricted  to  the 
use  of  radhard  components. 

Second,  the  fault  tolerant  system  can  be  utilized  as  a  testbed  to  analyze  software 
fault  tolerant  programs.  The  fault  tolerance  hardware  is  able  to  detect  the  SEU  and  log 
the  time  and  kind  of  an  upset.  The  software  can  then  be  observed  in  the  manner  in  which 
it  handles  the  error.  This  testbed  will  allow  the  testing  of  software  in  a  simulated  space 
environment  prior  to  use  in  orbit. 

Last,  the  system  can  be  utilized  as  a  hybrid  fault  tolerant  computer  system.  In  this 
configuration,  the  processor  is  additionally  monitored  for  SEU.  Upon  detecting  an  upset, 
the  processor  is  restored  to  the  state  prior  to  the  upset.  The  processor  then  continues 
execution  from  the  point  prior  to  the  upset  with  little  downtime  and  no  loss  of  data.  This 
is  dramatically  different  from  current  operations  where  a  processor  is  reset  when  an  error 
occurs,  resulting  in  downtime,  loss  of  data  and  spacecraft  availability.  As  shown,  this  is  a 
major  advance  in  the  handling  of  spacecraft  system  failures. 

E.  THESIS  ORGANIZATION 

The  organization  of  this  thesis  follows  the  design  approach  used  in  developing  the 
system.  Chapter  I  has  been  a  brief  introduction  of  the  environment  in  which  the  system 
will  be  operating.  Chapter  II  is  background  material  on  research  that  has  led  to  the 
foundation  and  fabrication  of  this  design.  Chapter  HI  contains  the  programming,  testing, 
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and  implementation  of  the  programmable  elements  of  the  system.  Chapter  IV  presents  the 
design  and  programming  of  the  system  controller.  Chapter  V  presents  the  final  steps  in 
design  completion.  Chapter  VI  presents  the  steps  that  were  taken  in  testing  the  design 
after  manufacture.  Chapter  VII  presents  steps  required  to  transition  the  current  test  bed 
design  to  a  flight  ready  design.  Chapter  VIII  presents  the  conclusions  developed  during 
this  research  and  discusses  topics  for  follow-on  work. 
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II.  BACKGROUND 


Fault  tolerance  has  been  implemented  in  computers  for  many  years.  A  digital 
system,  though  very  reliable,  does  not  operate  fault  free.  When  a  system  experiences  a 
fault,  it  has  to  be  detected  and  corrected.  The  technology  of  computer  systems  has 
progressed  at  a  rapid  rate  and  many  fault  tolerance  requirements  have  been  dropped  in 
order  to  improve  speed  or  performance.  However,  the  Department  of  Defense  requires 
the  use  of  fault  tolerant  designs  in  systems  that  perform  critical  tasks,  such  as  the  control 
system  of  the  F-l  17  stealth  aircraft.  A  minor  fault  in  the  computer  during  flight  would 
mean  disaster  for  the  aircraft.  This  level  of  performance  has  maintained  the  practice  of 
fault  tolerance  methods  at  the  forefront  many  of  designs.  [Ref.  8] 

The  purpose  of  this  chapter  is  to  provide  the  reader  with  a  brief  background  of  this 
project.  The  chapter  starts  by  outlining  the  general  concept  of  fault  tolerance  and  focuses 
in  on  the  design  and  implementation  of  this  system. 

A.  FAULT  TOLERANCE 

There  are  two  approaches  to  increase  the  survivability  or  reliability  of  electronics 
in  a  spacecraft,  which  are  radiation  hardening  and  the  use  fault  tolerance.  Figure  2.1 
provides  a  flow  diagram  for  the  design  of  a  reliable  system.  The  first  method,  radiation 
hardening  of  devices,  is  simply  constructing  devices  in  such  a  way  as  to  increase  the  total 
dose  survivability  and  reduce  the  possibility  of  an  SEP.  Four  basic  ways  to  harden  a 
device  are  with  junction  isolation,  dielectric  isolation,  silicon-on-sapphire  devices,  and 
silicon-on-insulator  devices.  This  method  would  relate  to  the  left-hand  side  path 
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designing  a  system  with  fault  avoidance  by  utilizing  parts  with  a  high  reliability.  This 
system  design  has  increased  radiation  tolerance,  but  offers  little  or  no  redundancy. 

The  second  method,  fault  tolerance,  follows  the  right  side  of  the  figure  and  is 
simply  the  ability  of  the  spacecraft  to  functionally  operate  in  the  presence  of  a  fault.  Fault 
tolerance  is  usually  achieved  by  increasing  the  redundancy  of  onboard  systems. 
Reliability  is  determined  by  the  design  of  the  system,  the  parts  utilized,  and  the  operating 
environment.  One  method  of  increasing  reliability  is  by  employing  the  worst-case  design, 
using  high  quality  components,  which  in  turn  adds  cost.  An  alternative  method  of 
improving  spacecraft  reliability  is  to  use  a  fault-tolerant  design.  Fault  tolerance  can  be 
accomplished  in  either  software  or  hardware.  This  section  will  discuss  the  redundancy 
methods  that  are  relevant  to  this  design,  which  are  time,  software,  passive,  and  hardware 
redundancy.  [Refs.  9  and  10] 


Figure  2.1.  Strategies  in  Designing  a  Reliable  System.  From  Ref.  [9] 
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1.  Time  Redundancy 

Time  redundancy  is  one  of  the  easiest  methods  to  implement;  it  involves  the 
restoration  of  a  system  to  the  point  immediately  after  experiencing  a  fault.  This  fault  is 
detected  by  placing  checkpoints  and  with  a  timeout  mechanism.  If  the  system  fails  to 
perform  a  task  within  a  certain  amount  of  time,  a  fault  is  detected:  The  restoration'  of  the 
system  is  accomplished  by  rollback  of  instructions,  segments  of  programs  or  entire 
programs  to  the  last  checkpoint.  The  problem  with  this  method  is  that  it  can  be  time 
consuming,  which  is  determined  by  the  size  of  the  program  and  memory  that  is  restored. 
Additionally,  there  is  a  loss  of  information  to  the  point  that  the  system  last  saved  data. 
[Ref.  10] 

An  alternative  method  of  time  redundancy  is  the  performance  of  a  calculation 
numerous  times  for  accuracy.  This  requires  the  system  to  save  the  state  before  the 
calculation,  perform  the  calculation  and  save  it,  make  a  context  switch  back  to  the 
beginning  of  the  calculation,  perform  it  again,  and  then  compare  the  results  of  the  two 
different  calculations.  This  results  in  a  large  computational  drain  on  the  system  and  two¬ 
fold  increase  in  calculation  time.  [Ref.  10] 

2.  Software  Redundancy 

No  matter  how  capable  the  programmer,  almost  all  software  contains  faults.  A 
way  to  achieve  some  level  of  protection  from  these  faults  is  the  implementation  of  a 
software  redundancy  method.  One  such  method  is  N-version  programming,  which  is  the 
addition  of  software  modules  to  provide  checks.  For  example,  five  individual  programs 
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are  designed  for  the  same  function.  They  are  all  executed,  and  their  outputs  are  voted 
upon.  Additional  methods  of  software  redundancy  are  consistency  checks  of  the  data 
against  known  correct  values  and  capability  checks  to  ensure  those  functional  programs 
are  operating  correctly.  [Ref.  10] 

A  subset  of  software  redundancy  is  error-correcting  codes.  These  codes  can  be 
utilized  to  provide  automatic  fault  detection.  One  of  the  best-known  codes,  the  Hamming 
single  error  correcting  code,  is  used  to  increase  reliability  of  information  transmitted  or 
stored  in  memories.  [Ref.  10] 

3.  Passive  Redundancy 

Passive  redundancy  employs  multiple  units,  some  of  which  are  not  continuously 
operating  and  are  command  selectable.  In  this  configuration,  redundant  items  act  in 
response  to  a  specific  failure  or  anomaly.  The  detection  of  a  fault  is  achieved  by 
conducting  periodic  tests,  self-checking  circuits,  or  watchdog  timers.  Passive  redundancy 
allows  mission  operations  to  continue  in  the  presence  of  one  or  more  failures.  [Ref.  10] 

4.  Hardware  Redundancy 

The  most  widely  accepted  view  of  hardware  redundancy  is  the  addition  of 
components.  Hardware  redundancy  can  be  broken  into  two  subcategories:  static  and 
dynamic.  Static  redundancy,  also  known  as  masking  redundancy,  is  the  addition  of  extra 
component  to  mask  out  a  fault  near  instantaneously.  One  of  the  major  methods  utilized  to 
accomplish  this  is  Triple  Modular  Redundancy  or  TMR.  Dynamic  Redundancy  is 
implemented  by  monitoring  the  operation  of  the  numerous  devices  for  a  fault.  In  this 
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system,  only  one  module  or  device  is  operating  at  a  time.  If  a  fault  is  detected  in  this 
operational  device,  it  is  switched  and  replaced  by  another  device.  [Ref.  10] 

The  design  described  in  the  following  chapters  of  the  paper  and  employed  in  this 
system  is  Triple  Modular  Redundancy,  a  hardware  redundancy  technique.  The  TMR 
concept  is  implemented  by  utilizing  three  identical  modules  that  feed  their  output  to  a 
voting  unit.  This  voting  unit  then  compares  the  outputs  and  passes  the  majority  vote  to 
the  output,  essentially  masking  out  any  single  fault. 

a )  Triple  Modular  Redundancy  ( TMR ) 

As  stated  before,  TMR  is  implemented  by  the  replication  of  the  devices 
and  performing  a  majority  vote  to  determine  the  output  of  the  system.  For  example,  if 
Module  A  becomes  faulty,  the  two  remaining  module’s  outputs  mask  the  fault  when  the 
majority  vote  is  performed.  The  inputs  and  outputs  of  a  module  do  not  have  to  be  single 
bytes.  A  word  can  be  inputted  into  a  module  to  produce  a  word  output.  This  word  has  to 
then  be  inputted  into  parallel  voting  units  to  vote.  The  basic  concept  of  the  TMR  circuit 
is  shown  below  in  Figure  2. 1 

The  concept  of  TMR  can  be  expanded  to  include  multiple  voting  modules 
to  produce  an  N-modular  redundant  system.  As  N  gets  larger,  the  logic  required  to 
realize  the  circuit  and  the  added  levels  of  delay  get  excessive.  The  typical  range  for  N  is 
from  three  to  five.  [Ref.  10] 
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Input  2 

Input  3 

ModC 

Figure  2.2.  Basic  TMR  Circuit  Implementation.  From  Ref.  [1] 

The  TMR  system  does  have  drawbacks,  the  primary  being  that  the  voter  is 
a  single  point  of  failure.  If  the  voter  fails  for  some  reason,  the  system  will  crash  or 
propagate  errors.  A  method  to  prevent  this  problem  is  the  use  of  triplicated  voters.  [Ref. 
10] 

B.  TMR  MICROPROCESSOR  DESIGN 

The  framework  for  the  system  in  this  design  was  first  developed  and  simulated 
using  Verilog  by  Lieutenant  John  C.  Payne,  Jr.,  USN,  as  a  Fault  Tolerant  Computing 
Testbed  [Ref.  1],  Following  this  Captain  David  Summers,  USMC  implemented  and 
fabricated  the  design  [Ref.  2],  The  remainder  of  this  section  is  a  brief  synopsis  of  the 
TMR  Testbed  Design. 
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1.  Hardware  Design  and  Operation 

The  first  step  in  the  design  process  was  the  integration  of  the  system  components. 
As  stated  previously,  TMR  is  implemented  by  on  the  replication  of  three  modules.  This 
design  was  first  focused  on  the  3081  as  a  single  system  and  then  triplicated.  Figure  2.3 
demonstrates  the  implementation  of  this  concept.  The  TMR  implementation  has 
relatively  few  changes  from  the  single  processor  design.  The  major  additions  to  the 
design  were  the  data,  address,  and  control  voter  components. 

As  shown  in  Figure  2.3,  the  three  system  processors  are  connected  in  parallel. 
The  system  acts  as  if  only  one  processor  is  present  in  the  system.  The  processors  perform 
functions  in  a  lock  step  manner  from  initial  boot  up  by  executing  the  same  instructions. 
The  processors  then  route  address,  data,  and  control  information  through  busses  to  their 
respective  voters.  The  voters  perform  a  majority  vote  on  the  signals  and  pass  them  on  to 
the  Memory  Space  and  Memory  Controller  as  in  a  single  processor  system.  If  an  error  is 
detected  in  a  voter,  the  Memory  Controller  generates  an  interrupt. 
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Figure  2.3.  TMR  R3081  Board  Design.  From  Ref.  [1] 


2.  Fault  Detection 

Though  the  voters  mask  out  the  fault  generated  in  the  data  going  to  memory,  the 
problem  remains  of  detecting  which  processor  was  at  fault  and  where.  In  order  to 
accomplish  this,  the  internal  registers  of  each  processor  have  to  be  stored  and  examined. 
The  information  (address,  data,  and  control)  is  captured  prior  to  being  voted  by  placing 
First-In-First-Out  (FIFO)  Registers  on  the  address,  control,  and  data  busses  between  the 
processors  and  voters.  If  an  error  is  detected,  by  any  of  the  voters,  the  current  bus  cycle 
completes  and  an  interrupt  is  generated.  The  processors  are  then  restored  to  the  state 
prior  to  the  fault  and  resume  operation.  The  arrangement  is  shown  below  in  Figure  2.4. 
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This  design  protects  only  the  processor  operation  and  the  processor  output.  The 
reliability  of  the  data  stored  in  the  memory  is  not  improved.  This  issue  is  discussed  in 
Chapter  VI  as  a  part  of  the  required  preparations  for  a  space  flight  design. 


Figure  2.4.  TMR  FIFO  Interface.  From  Ref.  [2] 


C.  DESIGN  IMPLEMENTATION 

Lt.  Payne’s  design  and  simulations  were  the  framework  for  the  concept  of  the 
TMR  system.  His  design  product  was  software  verification  in  Verilog  of  this 
implementation  of  TMR.  The  thesis  presented  by  Capt.  David  Summers  [Ref.  2] 
describes  the  implementation  of  the  TMR  design  in  hardware  and  the  required  changes. 
The  following  sections  will  provide  a  brief  overview  of  these  design  changes  and  further 
information  regarding  them  can  be  found  in  Reference  9. 
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1.  Design  Hardware  Changes 

The  process  in  the  design  of  any  system  is  driven  by  many  factors  including  part 
availability  and  compatibly.  Capt.  Summers  was  required  to  implement  design  changes 
in  order  to  provide  a  working  board  for  future  test  and  space  applications.  The  three 
major  changes  implemented  were  the  addition  of  a  system  controller  FPGA  and  I/O 
interface  ports.  The  system  controller  FPGA  was  added  to  replace  some  of  the 
functionality  provided  by  the  computer  in  the  Verilog  design.  The  I/O  interface  was 
added  to  provide  a  method  to  upload  programs  and  control  the  board  during  testing.  The 
design  and  implementation  of  the  system  controller  FPGA  is  covered  in  this  thesis. 
Additional  support  elements  such  as  oscillators,  buffers,  and  a  reset  circuit  were  also 
added  to  the  design.  These  design  changes  are  highlighted  and  shown  in  Figure  2.5. 

2.  Final  Design 

The  design  and  manufacture  of  the  TMR  board  were  completed  by  Capt. 
Summers,  but  he  was  unable  to  complete  the  programming,  test,  and  verification  of  the 
design.  This  thesis  continues  the  preparation  of  the  board  for  eventual  cyclotron  testing 
and  spacebased  applications.  This  author  began  work  on  the  TMR  design  with  Capt. 
Summers  on  the  design  of  the  PLDs,  FPGAs  programs  and  the  detailed  timing  analysis. 
This  joint  effort  was  presented  in  Capt.  Summer’s  thesis  as  Chapter  IV.  Chapter  IE 
presents  the  continuation  of  this  initial  effort  with  the  programming  and  testing  of  the 
Programmable  Logic  Devices  (PLD). 
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Figure  2.5.  TMR  R3081  Block  Diagram.  After  Ref.  [2] 
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ffl.  PROGRAMMABLE  LOGIC  DESIGN  AND  TESTING 

Designers  are  continuously  challenged  to  add  more  logic  to  system  while  using  the 
same  amount  of  board  space.  In  order  to  incorporate  this  in  the  TMR  design,  the  Memory 
Controller  and  Memory  Enable  functions  were  implemented  in  Programmable  Logic 
Devices  (PLDs),  and  Field  Programmable  gates  arrays  (FPGAs)  were  used  to  implement 
the  data,  control,  and  address  voting  logic.  The  programmable  logic  components  of  the 
design  are  identified  as  shaded  blocks  in  Figure  3.1. 


Figure  3.1.  Programmable  Logic  Device  Identifier.  After  Ref.  [2] 
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A. 


PLD  PROGRAMMING 


The  final  system  design  shown  in  Figure  3.1  utilized  four  user-defined  modules, 
which  are  the  address/voter  demux,  data/control  voter,  system  controller  and  the  memory 
and  error  controller.  The  first  three  modules  were  implemented  utilizing  Xilinx  FPGAs 
are  discussed  in  later  sections.  The  memory  and  error  controller  modules  were 
implemented  in  the  TMR  design  utilizing  two  Atmel  ATF22V10C-7PC  PLDs.  Detailed 
information  regarding  device  selection  and  program  logic  is  found  in  Reference  2  Chapter 
IV.  This  chapter  will  describe  the  steps  taken  in  the  programming  and  testing  of  these 
devices. 

The  software  program  utilized  to  construct  files  for  download  to  the  PLD  is  a 
program  called  WinCUPL,  which  is  a  Windows  version  of  Universal  Compiler  for 
Programmable  Logic  (CUPL).  CUPL  is  a  HDL  (Hardware  Description  Language) 
comparable  to  ABEL  used  to  program  logic  devices.  The  input  to  WinCUPL  is  a  user 
created  Programmable  Logic  Device  (PLD)  file  and  the  output  is  a  standard  JEDEC  file 
used  to  program  the  device.  After  compiling,  the  JEDEC  file  is  downloaded  to  a 
programming  unit  to  program  the  device  fuses.  The  program  device  utilized  in  the  design 
of  this  system  is  the  ALLPRO  96  256  Pin  programming  system  by  Logical  Devices,  Inc. 
After  the  file  is  downloaded,  it  is  programmed  into  the  device  and  the  logic  output  of 
device  is  compared  against  test  vectors.  The  following  sections  give  a  brief  synopsis  of 
the  purpose  of  the  devices  and  the  testing  and  verification  procedures. 
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1.  Memory  Controller  PLD 

The  main  function  of  the  memory  controller  is  to  provide  all  of  the  signals 
necessary  for  memory  access  during  bus  cycles.  The  memory  controller  inputs  consist  of 
the  chip  select  signal  for  all  peripheral  devices  such  as  RAM,  ROM,  timer,  UART,  and 
voter  interrupt.  Additionally,  the  voted  signal  such  as  read,  write,  data,  address,  and 
control  vote  errors  are  inputted  to  the  memory  controller.  These  inputs  are  utilized  to 
generate  the  vote  interrupt,  read/write  cycle  enable,  acknowledge,  bus  error,  and  cycle  end 
signals.  Appendix  A  gives  a  detailed  pin  out  of  the  Memory  Controller  PLD. 

2.  Memory  Enable  PLD 

The  Memory  Enable  PLD  assists  the  Memory  Control  PLD  during  bus 
transactions.  It  accomplishes  this  by  producing  the  read  and  write  enable  strobes  for  the 
memory  system,  read  and  write  data  enable  signals  to  control  the  drivers  on  chips 
between  the  busses,  and  a  positive  and  negative  logic  synchronous  reset.  Inputs  to  the 
PLD  consist  of  the  voted  read/write  and  voted  byte  enable  signal.  Utilizing  these  inputs, 
the  PLD  outputs  the  write  and  read  enable  signals  for  the  peripheral  devices. 

B.  PLD  TESTING 

Test  vectors  allow  the  designer  to  verify,  test  and  debug  a  PLD  design  for  proper 
functionality  before  it  is  used  in  the  system.  Though  the  test  vectors  can  pass  when  tested 
on  the  CUPL  functional  simulation,  the  same  vectors  may  fail  when  tested  on  the  PLD 
programmer.  This  is  the  case  with  the  memory  controller  PLD  that  had  two  vectors  fail. 
Two  reasons  that  this  could  occur  are  improper  test  vector  usage  and  a  result  of  the 
programmer’s  hardware  characteristics.  The  programming  hardware  dictates  the 
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sequence  in  which  inputs  in  a  given  vector  are  applied  to  the  device.  Analysis  of  device 
output  and  logic  equations  is  the  only  manner  by  which  to  analyze  and  correct  this. 
Analysis  of  the  device  output  led  to  the  conclusion  that  the  PLD  was  unable  to  latch  the 
counter  causing  the  vector  failures.  The  PLD  program  file  was  modified  to  correct  this 
error  and  passed  both  the  simulation  and  programmer  tests.  The  impact  of  the  change  to 
the  PLD  functionality  is  that  the  bus  error  and  cycle  end  signal  will  assert  on  one  clock 
earlier.  This  is  no  manner  affects  the  function  of  the  TMR  system.  After  completing  the 
program  changes,  the  file  was  compiled  and  downloaded  into  the  programmer. 
Programming  of  the  PLD  passed  all  test  vectors  successfully.  An  updated  design  file  is 
given  in  Appendix  A. 

C.  FPGA  PROGRAMMING 

The  field  programmable  device  chosen  for  this  system  is  the  Xilinx  XL4013XLA. 
These  devices  are  utilized  to  implement  address  voter\demux,  data\control  voter,  and  the 
system  controller  shown  in  Figure  3.1.  Reference  2  Chapter  IV  gives  a  detailed 
discussion  on  the  selection  of  this  device  and  the  design  of  the  programs.  The  software 
used  to  develop  the  program  for  the  devices  was  Xilinx  Foundation  Software.  The  FPGA 
design  is  a  3-step  process  that  consists  of  the  following  stages.  First,  design  entry,  in  this 
stage  of  the  design  flow  the  design  is  created  either  in  schematic  editor  or  hardware 
descriptor  language  (HDL).  Second,  design  implementation  by  mapping  the  file  to  a 
specific  Xilinx  architecture,  and  placing  and  routing  the  design,  the  design  file  created  in 
the  first  step  is  mapped  into  a  physical  file  format.  The  physical  information  contained  in 
this  file  is  then  used  to  create  a  bit  stream  file  for  programming  in  a  programmable 
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device.  The  final  stage  of  the  process  is  completed  when  the  bit  stream  file  is  formatted 
by  a  PROM  formatter  into  a  configuration  file  for  the  FPGA  device  that  can  be  stored  in  a 
PROM.  This  is  accomplished  by  converting  the  BIT  file  into  one  of  four  PROM  formats: 
MCS-86  (Intel),  EXORMAX  (Motorola),  TEKHEX  (Tektronix)  or  straight  HEX  format. 

In  a  joint  effort  with  Capt.  Summers,  the  first  two  steps  of  this  process  were 
executed.  [Ref.  2]  While  executing  the  third  step,  it  was  discovered  that  the  PROM  code 
formatter  in  this  software  is  targeted  for  Xilinx  parts  and  the  Serial  EEPROM  utilized  in 
this  design  was  an  ATMEL  AT17C512.  Further  research  into  the  impact  of  utilizing  this 
file  in  the  device  was  conducted  by  contacting  Xilinx  and  Atmel.  After  numerous 
conversations  with  the  two  companies,  it  was  concluded  that  the  Xilinx  software  program 
uses  the  device  selection  in  determining  the  allowable  size  of  the  prom  file  only. 
Therefore,  the  difference  in  device  was  acceptable  and  would  have  no  impact. 
Completing  the  process  the  file  was  formatted  into  MCS-86  and  TEKHEX,  then 
downloaded  to  the  ALLPRO  96  programmer  for  programming  into  the  Serial  EEPROM. 

In  order  to  accomplish  programming  of  a  device,  the  ALLRPO  has  to  first 
recognize  the  device  type.  The  device  programmer  was  unable  to  recognize  the  ATMEL 
devices  for  programming  and  thus  unable  to  program  the  serial  PROM.  Research  into 
possible  causes  for  this  failure  led  to  a  notice  on  the  ATMEL  website  [Ref.  11].  This 
notice  stated  that  some  ATMEL  serial  EEPROMs  failed  to  accept  device  encoding  during 
manufacture  and  listed  steps  to  overcome  this  failure.  The  instructions  detailed  methods 
of  switching  off  the  programmers’  device  recognition  function.  After  completing  the 
procedure  detailed  in  the  notice,  the  device  programmer  was  still  unable  to  program  the 
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device.  An  ATMEL  FPGA  engineer,  who  assisted  with  the  information  for  the 
programmer  was  aware  of  the  difficulties  experienced  in  programming  the  devices  and 
offered  assistance  with  programming  the  devices.  The  devices  were  returned  after 
programming  for  installation  in  the  system.  Verification  of  successful  programming  is 
only  indicated  by  the  programmer’s  comparison  of  the  contents  of  the  programmer 
memory  to  the  device  contents. 

The  programming  of  the  Memory  Controller  PLDs  and  the  Voter  FPGAs  allow 
the  system  to  function  as  a  stand-alone  computer  system  able  to  detect  and  correct  single 
bit  errors  occurring  in  any  of  the  processors.  The  design  of  the  system  controller  FPGA 
though  mentioned  in  the  start  of  this  chapter  was  not  discussed.  The  design  and 
programming  of  this  programmable  device  completes  the  TMR  design  and  is  discussed  in 
detail  in  following  chapter. 
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IV.  DESIGN  OF  THE  SYSTEM  CONTROLLER  FPGA 

As  stated  earlier,  programmable  logic  offers  flexibility  to  the  system  designer  and 
is  essential  to  performing  controlling  functions  in  the  TMR  3081  design.  The  Data  Voter 
and  Control  voter  were  previously  implemented  and  programmed  using  the  schematic 
editor  in  the  Xilinx  software.  The  System  controller  FPGA  presents  a  more  difficult 
design  problem  because  the  logic  implemented  by  this  controller  cannot  easily  be 
modeled  as  a  combinatorial  design.  Therefore,  it  was  decided  to  use  Xilinx  Foundation 
HDL  editor  and  State  Machine  tool  to  design  the  controller.  The  system  controller 
performs  numerous  functions  in  the  TMR  system.  It  initializes  the  Control  UART, 
enables  the  interrupts  for  the  308 1  microprocessor  after  resets,  transfers  and  collects  FIFO 
data,  and  defines  the  mode  in  which  the  TMR  system  functions.  In  examining  all  of  these 
tasks,  there  are  three  distinct  possibilities  of  data  flow.  These  are: 

•  The  FPGA  outputs  data  to  the  UART 

•  The  FPGA  enables  the  FIFO  to  output  data  to  the  UART 

•  The  FPGA  accepts  input  from  the  UART 

Each  of  these  events  is  mutually  exclusive:  that  is,  no  two  events  can  ever  occur  at 
the  same  instant  in  time.  It  is  the  function  of  the  system  controller  to  define,  which  one  of 
these  events  listed  above  is  presently  in  progress.  The  detailed  subsystem  programs  of 
the  system  controller  FPGA  are  listed  in  Appendix  B.  The  following  sections  discuss  the 
state  machines  for  each  subsystem  of  the  system  controller  FPGA.  Figure  4. 1  provides  an 
overview  of  the  flow  of  the  state  machines  discussed  in  the  following  sections. 
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Figure  4.1 .  State  Machine  Hierarchy 


A.  CHART  STATE  INIT  MACHINE 

The  Control  UART  Initialization  state  machine  is  the  uppermost  in  the  state 
machine  hierarchy.  It  automatically  initializes  the  UART  to  the  proper  mode  of  operation 
when  the  system  controller  FPGA  is  powered  on  or  reset.  The  following  sections  present 
the  operation  of  the  UARTINT  state  machine. 

1.  State  Machine  Functionality 

The  CUARTIN  state  machine  initializes  the  control  UART  to  communicate  with 
the  HCI.  This  is  accomplished  by  a  sequence  of  UART  register  writes.  The  first  register 
initialized  by  this  sequence  is  the  FIFO  control  register,  which  is  a  write  only  register. 
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The  register  enables  the  FIFO  by  asserting  the  first  bit.  The  next  register  in  the  sequence 
is  the  Line  control  register.  The  line  control  register  controls  the  format  of  the  data 
communication.  The  first  two  bit  in  the  register  are  set  to  T 1’  setting  the  serial  character 
word  length  to  8  bits.  The  last  six  bits  in  the  register  set  the  parity  and  number  of  stop 
bits.  The  Human  Control  Interface  design  by  Capt.  Kim  Whitehouse  and  LT.  Susan 
Groening  [Ref.  3]  currently  has  no  parameters  set  for  these  modes.  The  default 
initialization  sequence  therefore  sets  the  modes  for  no  parity  and  one  stop  bit.  The 
Modem  control  register  is  next  in  the  sequence  and  controls  an  interface  with  a  modem. 
The  assertion  of  the  first  two  bits  and  the  sixth  bit  in  the  register  enable  the  autoflow 
control  mode  of  the  UART.  The  final  registers  in  the  setup  sequence  are  the  Divisor 
Latch  (LSB)  and  Divisor  Latch  (MSB).  These  registers  are  utilized  to  control  the 
programmable  baud  generator  for  the  UART.  The  divisor  written  into  the  registers  is  72. 
This  divisor  sets  the  baud  rate  of  the  UART  to  9600.  The  final  state  of  the  UART 
initialization  sequence  disable  the  data  lines  and  deasserts  the  chip  select  line. 
Completion  of  UART  setup  enables  communication  with  the  HCI  and  allows  the  state 
machine  to  proceed  to  the  next  state  machine,  VOTE. 

The  CUARTINT  state  machine  initiates  in  state  SO  and  immediately  transitions  to 
the  next  state,  SI.  The  state  machine  shown  in  Figure  3.1  contains  no  conditions  for 
transitioning  from  state  to  state.  Therefore,  once  the  state  machine  is  initialized  it  does 
not  depend  on  any  outside  input  for  completion  of  the  control  UART  initialization 
process.  Continuing  in  state  SL  the  FSM  asserts  UART  Enable  (UARTEN)  and  Control 
UART  Chip  Select  (CUARTCSN).  The  assertion  of  these  signals  enables  the  UART  to 
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drive  the  bi-directional  bus  and  read  status  information  from  a  register.  In  the  next  state, 
S2,  the  FSM  first  asserts  the  Control  Address  bus  (CTRLADDR)  with  the  register 
selection  address.  The  UART  has  twelve  internal  registers,  only,  six  of  which  are  utilized 
during  the  initialization  process  discussed  in  this  section.  The  table  below  details  the 
register  selection  dependent  on  the  address  placed  on  the  CTRLADDR  bus. 


DLABt 

A2 

A1 

AO 

REGISTER 

0 

L 

L 

L 

Receiver  buffer  (read),  transmitter  holding  register  (write) 

0 

L 

L 

H 

Interrupt  enable  register 

X 

L 

H 

L 

interrupt  identification  register  (read  only) 

X 

L 

H 

L 

RFO  control  register  (write) 

X 

L 

H 

H 

Line  control  register 

X 

H 

L 

L 

Modem  control  register 

X 

H 

L 

H 

Line  status  register 

X 

H 

H 

L 

Modem  status  register 

X 

H 

H 

H 

1  Scratch  register 

1 

L 

L 

L 

Divisor  latch  (LS3) 

1 

L 

L 

H 

Divisor  latch  (MSS) 

Table  4.1.  UART  Control  Register.  From  Ref.  [12] 


In  addition  to  asserting  the  control  address,  state  S2  places  the  setup  data  on  the 
Control  Data  UART  (CTRLDATU)  bus  that  is  tied  to  the  bi-directional  Control  Data 
(CTRLDATA)  bus.  This  data  is  written  into  the  selected  register  and  latched  in  by  state 
S2b  with  the  assertion  of  the  Control  UART  Write  (CUWREN).  The  next  state  S3 
deasserts  CUWREN,  which  enables  the  next  state.  S4,  to  change  the  address  and  data 
lines  without  effecting  the  UART.  This  process  is  repeated  to  setup  remaining  registers. 
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Figure  4.2.  UARTC  State  Machine 


B.  VOTE  MACHINE 

The  vote  state  machine  is  the  primary  state  machine  of  the  system  controller 
FPGA.  This  state  machine  has  two  primary  purposes.  The  first  is  to  detect  a  voter 
interrupt  from  the  microprocessor  and  start  the  collect/transfer  state  machines.  The 
second  is  to  detect  a  Control  UART  Interrupt  (CUARTINT)  assertion  from  the  HCI.  The 


state  machine  is  broken  into  three  functions  to  ensure  control  over  what  state  machine  is 


driving  the  data  bus.  The  following  sections  discuss  the  operation  of  this  state  machine 
based  on  these  two  functions. 

1.  Voter  Interrupt  routine 

The  main  function  of  the  system  controller  FPGA  is  to  monitor  the  TMR  board 
for  a  vote  interrupt  to  collect  and  transfer  the  data.  This  important  function  is 
implemented  and  started  with  the  voter  interrupt  routine.  This  state  machine  detects  a 
voter  interrupt  and  increments  an  interrupt  counter.  The  incrementing  of  this  interrupt 
counter  is  a  signal  to  the  collect  and  transfer  state  machines  to  begin  the  process  of 
collecting  the  data  from  the  FIFOs  and  transferring  the  data  to  the  UART. 

The  state  machine  waits  in  state  SI  and  monitors  the  Interrupt  Chip  Select 
(INTCSN)  signal  for  indication  of  a  voter  interrupt.  When,  the  INTCSN  signal  is 
asserted,  the  state  machine  transitions  to  state  S2.  The  state  machine  then  waits  for  the 
deassertion  of  this  signal  indicating  that  a  voter  interrupt  has  been  serviced.  The  state 
machine  then  transitions  back  to  state  S 1  incrementing  the  Interrupt  Counter  (INTRCNT) 
register,  which  starts  the  Transfer  state  machine  discussed  in  a  later  section. 

The  state  machine  resides  in  this  state  until  assertion  of  the  CPUDONE  signal  by 
the  Transfer  state  machine.  Assertion  of  this  signal  indicates  that  the  Transfer  state 
machine  has  completed  the  transfer  of  the  CPUs  FIFO  array  contents  to  the  HCI.  The 
state  machine  transitions  to  state  S3  decrements  the  interrupt  counter  and  then  transitions 
back  to  state  SI  awaiting  another  interrupt  signal.  This  completes  the  detection  and  start 
of  the  interrupt  service  routine. 
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a)  INTRCNTR 

The  interrupt  counter  register  is  implemented  in  the  design  to  enable  the 


system  to  contend  with  numerous  consecutive  interrupts.  The  processors  will  have 
dumped  and  restored  their  internal  registers  before  the  system  controller  FPGA  is  finished 
transferring  the  FIFO  data.  The  state  machine  controls  this  by  incrementing  for  each- 
transition  of  INTCSN  signifying  to  the  state  machine  that  an  additional  interrupt  has  been 
serviced.  This  in  turn  will  ensure  seamless  operation  of  the  Transfer  state  machine  during 
multiple  interrupts.  Additionally,  it  is  important  to  note  that  INTRCNTR  is  a  4-bit 
register  and  therefore  the  maximum  number  of  interrupts  counted  by  this  machine  is  32. 
Since  the  collect  and  transfer  sequences  for  the  FIFO  are  occurring  simultaneously,  only 
an  extreme  error  condition  producing  consecutive  voter  interrupts  would  lead  the  state 
machine  exceeding  this  design  limit. 
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2.  UART  Interrupt  Routine 

Since  the  vote  state  machine  is  the  highest  in  the  hierarchy,  it  was  necessary  to 
implement  the  detection  of  a  request  from  the  HCI  to  input  data  to  the  system  controller 
FPGA  here.  The  HCI  inputs  data  through  the  UART  to  the  system  controller  to 
implement  three  functions,  which  are  a  board  level  reset,  a  system  level  reset,  or  to  set  the 
mode  of  operation  of  the  board  to  one  or  three  processors.  The  system  controller  detects 
this  request  for  input  and  starts  the  CONTROL  MODE  state  machine. 

An  alternate  transition  path  from  state  S 1  to  state  S4  is  caused  by  the  assertion  of 
the  Control  UART  Interrupt  (CUARTINT)  signal  with  the  INTRCNT  register  equal  to 
zero.  The  CUARTINT  signal  originates  from  the  UART  and  is  asserted  by  the  HCI 
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placing  data  in  the  UART.  Transitioning  to  state  S4  causes  the  assertion  of  the 
UARTTNT  signal  that  starts  the  CONTROL  MODE  state  machine.  This  state  machine  is 
discussed  in  the  following  section. 

3.  State  Machine  Design  Constraint 

An  important  factor  in  this  state  machine  design  is  the  imposed  constraint  that  a 
transition  to  state  S4  from  state  SI  is  inhibited  during  a  voter  interrupt  Service.  This  was 
accomplished  by  the  ANDing  of  the  signal  CUARTINT  and  1INTCNTR.  This  constraint 
was  placed  on  the  design  to  protect  against  switching  the  mode  of  operation  during  an 
interrupt  handling  routine.  An  example  of  this  is  switching  from  TMR  processor  mode  to 
one  processor  mode  during  a  voter  interrupt  service.  If  the  processors  are  currently 
dumping  their  registers  to  the  FIFO,  the  transfer  process  is  asserting  and  deasserting  the 
CTRLDATA  bus.  A  switch  in  mode  would  require  that  the  Read  Machine  drive  the 
CTRLDATA  bus  breaking  the  current  FIFO  data  dump.  Therefore,  it  was  decided  to 
block  this  function  from  occurring  until  completion  of  the  service  routine. 

This  basic  principle  is  also  implemented  in  the  design  of  the  HCI.  During  a  voter 
interrupt  routine,  the  HCI  is  receiving  FIFO  data  and  the  user  is  unable  to  halt  the  process. 
The  next  section  discusses  the  operation  of  the  Control  Mode  state  machine,  which  the 
HCI  utilizes  to  setup  the  TMR  system. 

C.  CONTROL  MODE  STATE  MACHINE 

The  vote  state  machine  initiates  the  control  mode  state  machine.  This  state 
machine  reads  in  the  control  word  from  the  UART  inputted  by  the  HCI.  The  state 
machine  next  utilizes  the  control  word  by  checking  what  bits  are  set  to  decide  which  of 
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the  three  functions  previously  mentioned  to  perform.  This  operation  of  this  state  machine 
flow  is  discussed  in  the  following  sections. 

1.  Mode  Initialization 

This  FSM  initializes  in  state  SI  and  transitions  to  state  S2  upon  assertion  of  the 
UARTINT  signal  by  the  VOTE  state  machine  discussed  previously.  State  S2  asserts  the 
signals  FORCE,  mode  enable  (MODEEN),  and  CUARTCSN  setting  the  default  mode  of 
the  TMR  design  to  single  processor  and  enabling  the  FSM  to  drive  the  bi-directional 
CTRLDATA  bus  for  input.  The  selection  of  the  default  mode  of  the  design  to  single 
processor  mode  is  to  allow  the  user  to  setup  the  system  design  and  conduct  initial  tests 
before  transitioning  to  the  TMR  mode.  This  selection  can  be  changed  in  future  designs. 
The  assertion  of  the  final  signal  CUARTCSN  indicates  to  the  UART  to  activate  the 
asynchronous  communications  element  for  data  transfer.  The  FSM  next  transitions  to 
state  S3,  asserting  the  CTRLADDR  bus  with  ‘000’  selecting  the  holding  register  (write) 
of  the  UART.  A  transition  to  state  S4  asserts  the  chip  select  signal,  CUARTADSN, 
which  allows  the  selection  of  the  control  register  in  the  UART.  The  state  machine  next 
transitions  to  state  S5,  asserting  Control  UART  Write  Enable  (CUWREN)  and  writing  the 
control  word  onto  the  data  lines.  Next,  state  S6  reads  in  the  data  on  the  input  bus  AIN 
tied  to  the  CTRLDATA  bus  and  places  the  contents  into  a  temporary  register  MDCTRL. 
The  FSM  transitions  to  state  S7  deasserting  CUWRENN,  CUARTCSN,  and  MODEEN 
allowing  the  other  state  machines  to  drive  the  bi-directional  data  bus  CTRLDATA.  State 
S7  has  three  possible  transition  paths  that  are  dependent  upon  the  data  in  MDCTRL 
register.  The  transition  paths  each  contain  an  ‘IF’  conditional  that  checks  a  bit  in  the 
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control  word  which  in  turn  selects  the  transition  path.  State  S10  causes  a  change  in  design 
mode  from  single  to  TMR  processor  mode.  State  SB  and  S9  are  responsible  for  a  board 
and  system  reset.  The  Control  Mode  state  machine  is  shown  in  figures  4.4  and  the 
control  mode  word  is  given  in  Appendix  B. 


Figure  4.4.  MODECNTRL  State  Machine 
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D.  FIFO  DATA  COLLECTION  STATE  MACHINE 

The  FIFO  data  collection  state  machine  as  the  name  implies  collects  the  FIFO 

array  data.  The  assertion  of  a  voter  interrupt  signal  causes  the  state  machine  to  assert  the 
read  enable  of  the  FIFO  arrays.  A  counter  increments  to  82  ensuring  the  FIFOs  read  in 
the  41  registers  data  and  address  saved  by  the  processor.  These  32  bits  of  information 
are  split  between  four  8-bit  FIFOs.  The  details  of  this  functional  state  machine  are  given 
in  the  following  section. 

1.  Data  Collection 

The  FIFO  data  collection  state  machine  resides  in  state  SO  until  the  assertion  of 
the  Voter  Interrupt  (VOTINT)  signal.  This  signal,  asserted  by  the  microprocessor, 
indicates  that  a  voter  interrupt  is  being  serviced  and  it  will  remain  asserted  until  the 
processors  have  completed  the  transfer  of  their  registers  to  memory.  Transitioning  to 
state  S2,  the  FSM  asserts  the  first  bit  on  all  the  FIFOCTRL  bus  lines.  Each  FIFO  array 
has  a  corresponding  control  line  designated  as  FIFOCTRLA,  B,  and  C.  This  first  line  is 
tied  to  the  Read  Enable  (RE)  pin  on  the  FIFO  allowing  it  to  read  in  data.  The  FSM  next 
transitions  to  state  S3  which  increments  the  Collect  Counter  register,  COLCNT.  This 
register  will  increment  up  to  82  before  allowing  the  machine  to  transition  to  state  four. 

After  counting  up  to  82,  the  state  machine  transitions  to  sate  S4  and  then  to  state 
SI  resetting  the  collect  count.  Keep  in  mind  while  this  is  occurring,  the  transfer  state 
machine  discussed  in  the  following  section  is  already  transferring  FIFO  data  with  the 
incrementing  of  the  interrupt  counter,  INTRCNT  register  by  the  VOTE  FSM. 
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Figure  4.5.  COLLECT  State  Machine 

E.  TRANSFER  STATE  MACHINE 

The  Transfer  state  machine  is  the  largest  state  machine  of  the  system  controller 
FPGA.  This  state  machine  performs  two  functions  first,  it  transfers  a  header  to  the  HCI 
system  to  identify  which  CPU  and  FIFO  is  being  transferred.  Second,  it  cycles  through 
the  FIFO  arrays  transferring  out  the  82  bytes  of  data  and  address.  In  designing  this  state 
machine,  it  was  essential  to  break  the  machine  into  four  separate  sections.  These  sections 
are  the  XFER,  CPU,  FEFOXFER,  and  BYTE  state  machines.  This  section  will  begin  by 
the  discussion  of  the  XFER  state  machine,  which  is  the  controller  of  the  transfer  FSM. 
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1.  XFER  State  Machine 


The  XFER  state  machine  is  the  dominant  FSM  in  this  design.  It  monitors  the 
INTRCNT  discussed  preciously  in  the  VOTE  machine  section.  When  the  counter  is 
incremented  the  state  machine  asserts  signal  to  commence  the  transfer  of  FIFO  data  to  the 
HCI. 

With  the  assertion  of  INTRCNTR,  the  FSM  transitions  to  the  XFERP  state  and 
asserts  the  Process  Transfer  (PROCXFER)  signal.  This  signal  is  used  to  start  the  transfer 
process  in  the  CPU  state  machine.  The  final  state  transition  occurs  when  the  INTRCNTR 
signal  equals  zeros  allowing  the  machine  to  transition  back  to  the  XFERSTRT  state 
deasserting  PROCXFER  and  switching  off  the  CPU  state  machine.  If  the  INTRCNT 
signal  is  incremented  while  this  state  machine  is  in  the  XFERSTART  state  then 
PROCXFER  remains  asserted  continuing  the  transfer  process  for  the  second  interrupt. 
The  XFER  FSM  is  shown  in  Figure  4.6. 
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Figure  4.6.  XFER  State  Machine 

2.  CPU  State  Machine 

The  function  of  this  machine  is  to  cycle  through  each  CPU  and  thereby  cycle 
through  the  corresponding  FIFO  array  for  that  CPU.  The  state  machine  is  started  by  the 
XFER  state  machine  and  commences  with  the  transfer  of  CPU  A  FIFOs.  The  transfer 
process  begins  with  the  assertion  of  a  signal  FEFOENG  to  enable  the  FIFO  transfer 
machine  and  the  setting  of  the  CPU  header  byte.  The  state  machine  resides  in  this  state 
until  a  counter  CPUCNT  is  incremented  indicating  completion  of  the  transfer  process. 
The  FIFOENG  signal  is  deasserted  disabling  that  set  of  FIFOs.  The  state  machine  then 
continues  the  process  with  the  next  CPU.  The  process  and  state  transition  is  discussed  in 
detail  in  the  following  paragraphs. 
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When  enabled  by  the  assertion  of  PROCXFER.  the  state  machine  transitions  from 
the  STRT  state  to  the  CPU  A  state  asserting  the  signals  FIFO  Engine  (FIFOENGA)  and 
CHDR[1:0].  The  BYTE  state  machine  in  forming  the  Header  byte  utilizes  the  Control 
Header  (CHDR)  signal.  Figure  4.7  shows  the  header  signal  format  formed  corresponding 
to  a  CPU. 


Bit  1 


BitO 


Processor 
00- A 
01  -B 
10-C 


Figure  4.7.  CHDR  Format 


The  FJFOENG  signal  is  specific  for  each  processor  and  is  utilized  in 
determination  of  what  transition  path  to  take  by  the  FIFOXFER  FSM.  The  assertion  of 
FIFOENG  starts  the  transfer  process  in  the  FIFOXFER  and  BYTE  state  machines.  The 
negation  of  this  signal  upon  exit  from  a  state,  for  example  FIFOENGA  transitioning  to 
zero,  causes  the  transfer  process  for  the  CPU  A  to  cease. 

State  to  state  transition  in  this  machine  is  dependent  upon  the  signal  CPU  Counter 
(CPUCNTR).  This  signal  is  controlled  by  the  FIFOEXFER  FSM  and  indicates  what 
CPU  is  being  serviced.  When  CPUCNTR  is  equal  to  3,  the  last  state  in  this  machine, 
CPUCOMP,  asserts  the  signal  XFERCOMP  that  indicates  to  the  VOTE  FSM  that  the 
XFER  FSM  has  completed  a  transfer  cycle.  The  CPU  State  machine  is  shown  in  Figure 
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3.  FIFOXFER  Engine  State  Machine 

The  next  FSM  in  the  hierarchy  is  the  FIFOXFER  FSM.  The  purpose  of  this 
machine  is  cycle  through  the  FIFOs  array  of  each  CPU.  This  FSM  waits  in  its  initial  state 
FSTART,  until  enabled  by  the  CPU  FSM.  When  the  FIFOENG  signal  is  asserted  by  the 
CPU  FSM  and  the  Header  Complete  (HCOMP)  signal  from  the  BYTE  transfer  FSM. 
discussed  next,  the  FSM  transitions  to  state  FIFOSTO.  The  assertion  of  the  HDONE 
indicates  that  the  header  byte  has  been  transferred.  This  functionality  was  necessary  to 
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allow  the  FPGA  to  drive  the  bi-directional  CTRLDATA  bus  before  enabling  the  FIFO  to 
drive  the  bus.  As  discussed  previously,  the  FIFOENG  signal  is  utilized  to  determine 
which  FIFO  control  lines  are  asserted.  The  transition  from  state  FIFOSTO  has  three 
possible  transitions  determined  by  the  FIFOENG  signal,  which  in  turn  enable  the 
assertion  of  three  control  buses  FIFOCTRLA.  FIFOCTRLB,  or  FIFOCTRLC.  This  design 
implementation  was  required  to  enable  the  FIFO  array  corresponding  to  the  appropriate 
CPU.  The  FIFO  Control  bus  is  1 1  bits  wide  with  only  the  last  10  bits  controlled  by  the 
FIFO  ENGINE  state  machine.  The  first  bit  of  the  control  line  is  controlled  by  the 
FIFODATA  state  machine  discussed  previously.  Upon  assertion  of  the  FIFOCTRLA  bus, 
the  BYTE  transfer  machine  begins  to  transfers  the  contents  of  the  FIFO  that  holds  the 
most  significant  byte  of  the  32-bit  address  and  data.  The  format  of  the  FEFOCTRL  word 
is  given  in  Figure  4.9. 


Bit 

Bit 

Bit 

Bit 

Bit 

Bit 

Bit  1  Bit 

Bit 

Bit 

Bit 
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6 

5 

4  1  3 
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1 

0 

FIFO 
00 -A 


FIFO  FIFO  FIFO  FIFO  FIFO 

00  -  B  00  -  C  00  -  D  00  -  E  WRITE 

ENABLE 

Figure  4.9.  FIFOCTRL  Word 


The  FIFOENG  state  machine  waits  in  state  FIFOSTO  until  assertion  of  the 
completion  signal  from  the  BYTE  Transfer  state  machine.  FIFOSTO  additionally  asserts 
the  FIFOHDR  register  that  is  used  in  determination  of  the  header  byte  by  the  BYTE 
Transfer  machine.  The  FSM  remains  in  this  state  until  the  FIFOCOMP  variable  is 
deasserted  indicating  that  the  BYTE  Transfer  machine  has  completed  the  transfer  of  a 
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FIFO's  contents.  The  state  machine  transitions  to  the  next  state  when  the  BYTE 
TRANSFER  machine  asserts  the  signal  HDONE  indicating  that  the  header  information 
has  been  sent.  The  appropriate  control  lines  are  asserted  during  the  transition  action  and 
this  process  is  repeated  until  state  FIFOST4.  This  state  indicates  completion  of  the 
transfer  of  the  last  FIFO  in  the  array.  Upon  assertion  of  the  FDFOCOMP  signal,  the  state 
machine  increments  the  register  CPUCNT  that  is  utilized  by  the  CPU  state  machine 
discussed  previously  to  enable  a  different  CPU  FIFO  array.  If  the  CPUCNT  is  equal  to 
two,  the  state  machine  takes  a  different  transaction  path  and  resets  CPUCNT  to  zero. 
This  FSM  is  shown  in  Figure  4.10. 
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4.  BYTE  Transfer  Machine 


The  final  FSM  in  the  transfer  hierarchy  is  the  BYTE  state  machine.  The  function 
of  this  state  machine  is  to  transfer  the  header  information  and  the  82  bytes  of  information 
from  each  FIFO  in  the  array.  Enabled  by  the  assertion  of  any  FIFOENG  signal,  the  state 
machine  transitions  from  the  BYTSTRT  state.  Transitioning  to  state  BYTE2,  the  FSM 
asserts  CUARTCSN  and  CTRLADDR  identifying  to  the  UART  the  specific  register  to 
write  the  data.  State  BYTES  next  asserts  the  address  strobe  signal,  CUARADSN,  and 
forms  the  header  on  the  CTRLDATA  output  by  OR’ing  the  contents  of  the  registers 
CHDR  and  FHDR.  This  state  additionally  asserts  the  signal  Header  Enable  (HDREN), 
which  allows  the  FSM  to  drive  the  bi-directional  CTRLDATA  bus  output  lines. 
Transitioning  to  state  BYT4,  the  state  machine  asserts  Control  UART  Read  Enable 
(CURDEN)  allowing  the  UART  to  read  in  data  on  the  CTRLDATA  bus.  The  state 
machine  transitions  to  state  BYTES  setting  the  signal  BYTCNT  equal  to  one.  This  signal 
is  used  to  control  the  number  of  transfers  that  the  BYTE  machine  conducts.  State  BYTE7 
deasserts  the  output  enable  signal,  HDREN,  allowing  the  FIFOs  to  drive  the  CTRLDATA 
bus.  This  state  also  asserts  the  signal  HDONE  indicating  to  the  FIFOXFER  machine  that 
the  header  information  has  been  transferred  allowing  it  to  assert  the  FIFOCTRL  lines. 
The  FSM  then  transitions  through  states  BTYE7  through  BYTEIO.  These  states  act  as  a 
‘FOR’  loop  cycling  the  data  out  of  each  FIFO  by  asserting  and  deasserting  FIFO  Write 
Clock  (FWRCLK)  signal.  Additionally,  as  the  FSM  cycles  between  these  states  the 
register  Byte  Count  (BYTCNT)  is  incremented.  When  the  BYTCNT  is  equal  to  eighty- 
two,  the  state  machine  transitions  to  state  BYTE1 1  asserting  the  FEFOCOMP  signal  and 
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the  FIFOCOMP  signal  and  deasserting  the  HDRDONE  signal.  The  state  machine  repeats 
the  process  with  the  machine  transitioning  through  the  states  until  the  FIFOENG  signal  is 
deasserted. 
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Figure  4. 1 1.  BYTE  Transfer  State  Machine 

The  completion  of  the  system  controller  design  finishes  the  design  and 
programming  of  the  programmable  logic  devices.  With  the  completion  of  these 
programmable  devices  and  installation  in  the  TMR  board,  the  only  remaining  change  to 
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implement  is  the  addition  of  white  wires.  The  next  chapter  presents  the  addition  of  the 


white  wire  and  required  design  changes. 


THIS  PAGE  INTENTIONALLY  LEFT  BLANK 
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V.  DESIGN  COMPLETION 


Any  design  when  transitioned  to  a  second  engineer  for  completion  is  a  difficult 
process.  The  new  engineer  not  only  has  to  have  confidence  in  the  design  of  his 
predecessor,  but  also  still  remain  alert  for  potential  problems.  This  chapter  discusses  the 
addition  of  required  logic  changes  with  the  addition  of  white  wires  and  the  discovery  and 
correction  of  a  hardware  incompatibility. 

A.  WHITE  WIRES 

The  addition  of  the  white  wires  to  add  additional  logic  to  the  TMR  design  was 
discussed  in  Reference  [2].  The  main  concern  of  this  author  was  the  difficulty  with  the 
addition  of  these  wires.  The  white  wires  required  were  primarily  from  the  Xilinx  FPGAs, 
which  are  240  pin  devices.  The  small  scale  of  this  device  required  a  high  level  of  skill  to 
implement  the  changes. 

The  changes  were  completed  with  the  assistance  and  expertise  of  David 
Rigmaiden  of  the  Space  Systems  Academic  Group.  Utilizing  a  precise  soldering  station 
and  microscope,  the  addition  of  the  white  wires  took  over  a  day  and  a  half.  The  soldering 
of  the  pins  to  the  FPGA  required  a  high  degree  of  precision  and  was  very  time  intensive. 
With  the  addition  of  the  w'hite  wires  complete,  the  TMR  R308 1  system  was  ready  for 
initial  testing. 

B.  VOLTAGE  REGULATOR 

As  discussed  earlier  any  transition  of  a  design  from  one  engineer  to  a  follow  on 
engineer  is  a  wary'  process.  Upon  transition  of  the  board  from  Capt.  Summers,  it  was 
necessary  to  conduct  a  thorough  review  of  the  design.  It  was  during  this  review  and  the 
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power/ground  checks  discussed  in  chapter  VI  that  a  device  compatibility  problem  was 
found. 

The  Xilinx  FPGA  utilized  in  the  design  fabrication  was  the  XC4013-XLA.  These 
devices  provide  the  voting  function  that  is  the  cornerstone  of  the  design.  The  FPGAs 
soldered  to  the  board  required  a  supply  voltage  of  3.3  Volts.  This  posed  a  problem  since 
the  TMR  board  contained  a  5-Volt  and  12-Volt  bus.  There  were  two  possible  solutions  to 
this  problem.  The  first  was  to  purchase  new  5-Volt  FPGAs  and  replace  the  3.3V  FPGAs. 
The  second  possible  solution  was  to  create  a  3.3V  bus  for  the  FPGAs. 

The  first  solution  though  sounding  simplistic  was  quite  difficult.  The  240  pin 
FPGA  is  a  flat  pack  device  precisely  soldered  to  the  board.  The  unsoldering  of  these 
devices  would  lead  to  their  destruction.  The  difficulty  then  came  of  soldering  the  new 
devices  to  the  board.  The  expertise  and  precision  that  was  required  to  the  soldered  the 
devices  is  very  labor  intensive.  The  slightest  error  though  would  lead  to  faults  in  the 
board  and  would  have  dramatic  effects  on  any  troubleshooting. 

The  second  solution,  the  addition  of  a  3-Volt  bus  to  the  board  for  the  FPGAs 
sounded  more  promising.  The  only  problem  with  this  solution  was  the  impact  of  noise  on 
the  FPGA. 

It  was  decided  to  proceed  with  the  addition  of  a  3-Volt  bus  to  the  TMR  design. 
This  solution  posed  the  minimal  amount  of  difficulty.  Additionally,  this  was  a  low  cost 
solution  when  compared  with  the  cost  of  new  FPGAs.  The  following  sections  discuss  the 
selection  of  the  Voltage  Regulator  and  the  addition  of  the  3V  bus. 
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1.  Voltage  Regulator 

The  selection  of  a  voltage  regulator  first  required  the  calculation  of  the  current 
requirement  of  the  FPGAs.  The  Xilinx  website  details  a  formula  that  is  dependent  on  the 
number  of  logic  cells  utilized  in  the  design.  [Ref.  13] 

Plnt=  Vcc  *  Kp  *  Fmax  *  NLc  *  TogLc 

Where:  Vcc  =  3.3  V;  Kp  =28xl0'!2:  Fmax=25Mhz;  NLC=1300;  Tog^.20 

Kp  is  a  constant,  which  depends  on  the  logic  family.  Nlc  is  the  number  of  logic 
cells  used  in  the  design.  For  the  worst-case  scenario,  the  maximum  number  of  logic  cells 
was  utilized.  Togu:  is  the  average  percentage  of  logic  cells  toggling  at  each  clock.  The 
Xilinx  recommend  a  using  20  percent  for  this  value. 

The  calculated  power  requirement  for  each  FPGA  was  .6006  Watts.  Then  using 
the  total  wattage  of  1.8  and  the  input  voltage  of  3.3  Volts,  a  current  estimate  of  .546 
Amps  was  calculated.  Utilizing  this  information,  the  Maxim  832  voltage  regulator  was 
selected.  This  fixed  3-Volt  voltage  regulator  has  an  8  V  to  30  Volt  input  ranges  and  is 
rated  at  1  Amp.  Now  with  the  device  selected,  a  design  to  add  the  3-Volt  bus  to  the 
TMR  system  was  required. 

2.  3- Volt  Bus 

The  addition  of  a  three-Volt  bus  to  the  three  FPGAs  on  the  TMR  board  required  a 
high  level  of  skill  and  expertise.  Each  FPGA  had  16  VCC  pins.  Additionally,  each 
FPGA  had  a  number  of  capacitors.  The  first  step  in  the  process  was  to  unsolder  a  pin  on 


an  FPGA  and  discover  the  amount  of  it  would  permit.  Keep  in  mind  that  all  of  this  work 
is  accomplished  with  a  microscope.  The  first  pin  on  the  system  controller  FPGA  when 
unsolder  from  the  board  would  only  permit  about  a  20  degree  bend.  The  pins  on  the 
FPGA  are  extremely  delicate  and  the  danger  of  reaching  the  breaking  point  w'as  high. 
The  remaining  pins  on  one  side  of  the  FPGA  were  unsolder  and  lifted  to  the  same  angle. 

The  next  step  was  to  solder  a  wire  to  create  the  3V  bus.  The  first  step  consisted  of 
laying  a  small  strip  of  cellophane  tape  over  the  remaining  soldered  FPGA  pins  for 
protection.  The  distance  was  measured  between  the  lifted  pins  to  cut  small  tubing  for 
protection.  A  wire  was  then  solder  to  the  first  pin  and  the  small  tubing  slid  on.  This 
process  was  repeated  around  the  FPGA  creating  a  3-Volt  bus.  The  remaining  step  was  to 
unsolder  the  capacitor  leads  and  solder  them  to  the  bus.  The  completion  of  this  wired  bus 
around  the  each  FPGA  led  to  the  final  step  the  addition  of  the  voltage  regulator  board. 

In  order  to  make  the  addition  of  the  3-Volt  bus  to  the  board  simplistic  and 
permanent  in  nature  it  was  decided  to  use  an  evaluation  kit  provided  by  Maxim.  This  kit 
provides  a  regulated  5.0V  output  voltage  and  is  fully  tested  on  a  surface-mount  printed 
circuit  board.  The  kit  comes  with  a  MAX83 1  IC,  but  was  easily  converted  to  the  use  the 
MAX832  (3.3V  output).  After  soldering  the  MAX832  onto  the  board,  it  was  tested  to 
confirm  a  constant  3.3  Volt  1  Amp  output.  This  small  printed  circuit  board  was  then 
permanently  mounted  over  the  FIFOs  on  the  TMR  board.  The  output  from  the  board  was 
then  connected  to  buses  surrounding  the  FPGAs.  The  photograph  in  Figure  5.1  depicts 
the  work  and  components  discussed  above. 
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Figure  5.1.  MAXIM  Voltage  Regulator 


The  addition  of  the  voltage  regulator  marks  the  final  hardware  change 
implemented  to  the  design.  This  allowed  transition  to  the  next  phase  of  the  project, 
design  testing.  The  testing  phase  begins  with  basic  power  and  ground  checks,  which  is 


presented  in  the  next  chapter. 
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VI.  SYSTEM  TESTING 


When  testing  a  new  programmable  system  one  cannot  be  certain  whether  a 
specific  problem  or  “bug”  is  caused  by  the  hardware  being  faulty  or  if  the  software  is  in¬ 
correct.  The  objective  of  the  testing  is  to  identity  any  cause  for  a  malfunction  in  the 
shortest  possible  period  of  time.  Since  there  are  numerous  places  in  the  system  where 
problems  may  exist,  the  process  has  to  be  as  efficient  as  possible.  One  efficient  method 
of  testing  is  to  separate  it  into  phases  to  ensure  basic  operation  before  proceeding  to  more 
complete  functions.  This  method  was  utilized  in  the  testing  of  the  TMR  board  and  it  is 
broken  down  into  the  following  two  phases  of  initial  and  system  level  checks. 

A.  INITIAL  CHECKS 

Before  attempting  to  operate  the  system,  initial  checks  of  the  board  were 
conducted.  These  initial  checks  consisted  of  three  steps:  power/ground,  clock  signal  and 
reset  signal  testing.  The  purpose  of  this  initial  testing  is  to  ensure  safe  operation  of  the 
board  and  connectivity  to  system  devices.  Though  these  tests  may  seem  simple  and 
mundane,  the  bypassing  of  these  checks  could  lead  to  unnecessary  troubleshooting  in  later 
testing  phases  or  damage  to  components. 

1.  Power  Ground  Testing 

Before  powering  the  board,  it  is  essential  that  the  verification  of  the  connection  of 
power  and  ground  be  verified.  This  procedure  verifies  that  no  manufacture  defects  are 
present  in  the  board  from  fabrication.  The  chance  of  this  occurring  is  slight  as  a  result  of 
the  automation  used  in  the  fabrication  process,  but  the  potential  impacts  are  very  crucial. 
Bypassing  this  step  could  allow  a  shorted  pin  to  destroy  board  components  or  lead  to 
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unnecessary  errors.  This  procedure  was  conducted  utilizing  a  digital  multi-meter.  All 
component  level  power  and  ground  pins  were  verified  and  no  shorts  were  found.  It  was 
during  this  phase  of  the  testing  that  the  voltage  compatibility  problem  of  the  FPGAs  was 
discovered  and  verified.  The  FPGAs  utilized  in  the  board  fabrication  were  low  voltage 
devices,  while  the  board  was  designed  with  a  5-volt  bus.  The  solution  to  this  problem 
was  discussed  in  chapter  V.  The  completion  of  these  tests  certified  that  the  board  was 
safe  to  apply  power  to  and  enabled  movement  to  the  next  phase  of  testing  the  clock 
signals. 

2,  Clock  signal  testing 

Another  input  that  has  to  be  verified  that  affects  all  components  is  the  clock  input. 
The  clock  waveform  has  to  be  correct  in  terms  of  voltage  and  timing.  If  the  clock  inputs 
are  not  correct,  they  have  to  be  repaired  before  proceeding  to  the  next  step.  The  IDT3081 
does  not  have  a  definite  time  relationship  between  the  input  clock  and  the  SYSCLK 
output  signal.  The  IDT  manual  contains  a  clock  synchronization  algorithm  to  conduct 
upon  powering  up  the  board,  which  can  be  found  on  page  11-8  of  Reference  12.  This 
process  is  applicable  to  the  R308 1  multiple  processor  designs  utilizing  Vi  frequency  bus 
mode.  This  procedure  consists  of  performing  a  normal  reset  and  selecting  full  frequency 
bus  mode.  This  will  force  all  processors  to  align  the  phases  of  their  output  clocks.  Next, 
allow  reset  to  be  de-asserted  for  at  least  two  to  three  clock  cycles  and  then  assert  it.  Now 
select  one-half  frequency  bus  mode  and  de-assert  reset. 

Utilizing  an  Oscilloscope,  initial  test  of  the  TMR  board  verified  an  1 1  MHz  signal 
for  the  UART  and  an  intermittent  20  Mhz  clock  signal  for  the  3081.  The  20  MHz  clock 
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signal  is  inputted  to  the  microprocessor  an  output  as  a  10  MHz  clock  signal.  The 
measured  clock  input  to  the  3081  was  intermittent  and  tracing  the  difficulty  led  to  the 
oscillator.  Initially  a  failed  oscillator  was  suspected.  Further  troubleshooting  determined 
the  oscillator  had  a  bent  connector  that  was  not  allowing  proper  seating.  Upon  reseating, 
the  clock-input  signal  to  the  308 1  was  reliable. 

3.  Reset  Signal 

The  last  signal  to  verify  in  the  initial  testing  is  the  reset  logic.  The  reset  signal 
allows  for  the  FPGA  programming  to  be  completed  from  the  synchronous  PROMs  prior 
to  the  processor  attempting  to  make  a  memory  access.  This  time  period  allows  the  FPGA 
to  map  the  voting  and  address  control  logic.  If  this  did  not  occur  in  the  correct  logic 
sequence,  the  processor  would  experience  a  bus  error. 

The  logic  of  the  reset  sequence  was  tested  with  an  oscilloscope.  The  oscilloscope 
was  connected  to  the  reset  pin  of  the  3081  processor.  Then  by  asserting  the  board  or 
system  level  reset  push  button  the  assertion  of  the  reset  signal  was  observed  verifying 
correct  operation.  The  time  delay  for  the  reset  of  the  FPGA  is  unobservable.  This  step 
completes  the  initial  testing  phase  and  allowed  us  to  proceed  to  the  system  level  testing. 

B.  SYSTEM  LEVEL  TESTING 

By  completing  these  initial  electrical  checks  first,  the  scope  of  possible  trouble 
within  the  overall  system  was  minimized.  The  next  checks  confirm  proper  operation  of 
the  basic  system  components,  the  microprocessor,  memory,  and  UART.  The 
microprocessor  has  to  be  capable  of  reading  and  writing  data  to  and  from  memory  before 
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it  is  possible  to  proceed  to  further  testing.  The  first  step  in  this  process  is  the 
programming  of  the  microprocessor. 

1.  Processor  Initialization 

The  IDT3081  is  a  32-bit  RISC  microprocessor  that  is  designed  using  the  MIPS 
architecture  [Ref.  12].  Although  most  programming  occurs  using  high-level  language, 
like  “C”,  the  programming  during  the  testing  was  written  in  assembly  language.  This 
enabled  precise  control  and  setup  of  the  processor  structure  by  directly  initializing  the 
control  registers.  The  following  sections  will  first  discuss  the  operations  necessary  to 
initialize  the  3081  to  a  functional  state  and  then  the  operational  purpose  of  the  program. 
Keep  in  mind,  the  program  discussed  in  the  following  sections  and  given  in  Appendix  C 
sets  the  processor  in  a  known  state  for  uncached  operations  only. 

Before  discussing  the  execution  of  the  written  program,  this  section  will  impart  an 
understanding  of  the  process  of  creating  a  boot  program.  The  program  is  written  in 
assembly  language  programs  using  a  general  word  processor  such  as  Notepad.  This  file  is 
then  assembled  and  linked  using  the  Generic  Cross  Compiler  (GCC)  and  linker  provided 
by  IDT.  A  makefile,  which  is  similar  to  batch  file,  is  utilized  to  assemble  and  link  the  file 
automatically.  This  makefile  is  listed  in  Appendix  C  and  details  options  used  by  the 
compiler  and  linker.  One  important  fact  of  information  is  the  location  that  the  code  is 
assembled  to  start  at  in  memory,  which  is  at  address  OxlFCOOOOO.  After  a  hardware 
reset,  code  will  be  running  is  KSEG1  (uncached)  which  contains  address  OxlFCOOOOO. 
When  the  processor  is  setup  in  kernel  mode,  four  kemel/user  segments  (KUSEG) 
memory  spaces  are  available.  KSEG1  is  a  512  Mbytes  segment  that  is  used  for  I/O 
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registers  and  boot  ROM  code.  The  address  OxlFCOOOOO  corresponds  to  the  processor’s 
reset  vector.  The  processor  retrieves  the  first  instruction  here  and  begins  program 
execution  on  power-  up.  When  the  compiler  and  linker  have  assembled  the  file,  they 
output  a  memory  map  file,  a  binary  file,  and  a  Motorola  s-record  file  that  is  downloaded 
into  ROM.  The  S-record  file  is  downloaded  using  a  computer  into  a  device  programmer. 

The  next  step  in  the  process  is  to  prepare  the  ROM.  The  ROM  utilized  in  the 
TMR  design  is  the  AMD  27C010  128kx8  UV  erasable.  The  first  step  in  the  burning 
process  is  to  either  erase  the  devices  or  verify  they  are  blank.  This  is  accomplished  by 
placing  them  under  a  UV  lamp  for  a  period  of  20  to  40  minutes  erases  the  ROM.  The 
time  period  is  determined  by  the  life  of  the  devices.  The  more  erasures  a  device  has 
experienced  the  longer  the  period  of  time  to  erase  them.  Once  the  PROMs  are  erased  and 
tested  by  the  device  programmer  as  blank,  they  are  ready  to  bum. 

The  final  step  in  the  process  is  to  determine  if  the  file  has  to  be  split.  This  is 
determined  from  the  size  of  the  ROM  used  in  the  design.  For  example,  the  TMR  board  is 
using  four  128  x  8  PROMs  and  each  PROM  has  eight  data  output  lines.  Therefore,  the 
file  is  split  twice.  The  first  512K  splits  the  memory  in  half  and  the  next  512K  split 
separates  the  halves  again.  The  result  is  four  separate  data  blocks  that  are  programmed  in 
the  following  address  ranges  0-1FFFF,  2-3FFFF,  4-5FFFF,  and  6-7FFFF.  The  first 
PROM  outputs  data  on  lines  D0-D7,  the  second  D8-D15,  the  third  D16-D23,  and  the 
fourth  D24-D31. 
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a)  Status  Register 

Upon  reset  or  initialization,  the  IDT  3081  boots  up  in  an  unknown  state. 
The  programmer’s  first  priority  is  to  force  the  processor  into  a  known  state  by  writing  to 
the  status  register.  This  register  controls  the  setup  of  the  processor  and  memory 
management  functions.  The  32-bit  register  format  is  given  in  Figure  6.1. 
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Figure  6.1.  Status  Register  Format.  From  Ref.  [12] 


Only  a  few  of  the  bits  in  this  register  are  defined  after  hardware  reset 
initialization  which  are:  the  CPU  is  in  kernel  mode,  KUc=0,  interrupts  are  disabled, 
lec=0,  the  data  and  address  caches  are  not  swapped,  SWc=0,  and  the  processor  is  in 
bootstrap  mode,  BEV=1.  The  initialization  command  used  in  the  program  OR’d  three 
global  variables  SR_PE,  SR-CUO  and  SR_BEV.  These  global  variables  are  defined  in  a 
header  file  that  is  linked  with  the  main  program.  The  three  variables  represent  the  options 
chosen  for  the  boot  up  and  are  required  for  proper  operation.  This  command  is  written  to 
the  status  register  which  resets  the  parity  error,  set  Coprocessor  one  useable,  Coprocessor 
zero  to  kernel  mode,  clears  interrupt  masks,  and  set  the  processor  in  bootstrap  mode.  The 
assertion  of  the  Bootstrap  exception  vector  (BEV),  determines  the  location  of  the 
exception  vectors  of  the  processor.  The  boot  code  utilizes  uncached  space,  therefore  the 
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BEV  is  set  to  1,  and  the  exception  vectors  reside  in  unchacheable  space  versus  cacheable 
space. 

b)  The  Cause  Register 

The  cause  register  is  a  32-bit  register  that  describes  the  last  exception 
conducted  by  the  processor.  The  register’s  format  is  given  in  Figure  6.2.  With  the 
exception  of  the  Software  interrupt  or  SW  bits,  all  other  bits  in  this  register  are  read  only. 
The  SW  bits  can  be  utilized  to  force  an  interrupt  pending  signal  to  the  processor  or  clear  a 
pending  interrupt  by  writing  a  “0”.  This  last  step,  clearing  the  interrupts,  is  required  in 
initialization  of  the  3081.  In  the  program,  the  global  variable  C0_CAUSE  was  written  to 
the  register  to  clear  software  interrupts.  Further  information  on  any  of  the  fields  in  the 
Status  or  Cause  register  not  discussed  above  can  be  found  in  Reference  [13]. 
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Figure  6.2.  Cause  Register  Format.  From  Ref.  [12] 


c)  Functional  Testing 

One  of  the  most  difficult  problems  with  verifying  the  functionality  of  a 
system  is  the  possibility  of  software  errors.  If  the  software  does  not  properly  setup  the 
processor  or  function  in  the  designed  manner  then  the  overall  testing  of  the  system  is 
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worthless.  This  was  not  the  case  in  with  the  testing  of  the  TMR  board.  In  the  search  for 
research  information,  the  University  of  California  at  Davis  was  an  exceptional  source. 
Their  experience  with  the  ARGOS  satellite  project  on  Fault  Tolerance  software  design 
and  the  IDT  3081  was  a  source  outstanding  resource.  An  application  Engineer,  Mr. 
Lance  Halstead,  at  the  University  was  also  interested  in  building  programs  for  the  308 1 . 
Providing  him  with  copies  of  a  program  designed  and  developed  for  the  TMR  board,  he 
made  minor  modifications  for  his  specific  board  to  test  the  program.  The  program 
functioned  correctly  by  outputting  a  signal  to  LEDs  and  counter  on  his  board.  The 
verification  of  the  code  limits  functionality  problems  to  the  board  hardware  logic.  This  is 
a  major  step  in  the  design  process,  because  problems  are  limited  to  the  board  hardware 
design.  The  program  verification  by  an  outside  source  on  an  operational  design 
eliminates  the  possibility  of  software  errors. 

C.  TEST  DATA  AND  WAVEFORMS 

This  section  will  discuss  the  data  and  waveforms  measured  and  recorded  utilizing 
the  HP  16500B  digital  logic  signal  analyzer.  The  logic  analyzer  is  utilized  to  record  data 
on  signal  lines  throughout  the  TMR  design.  The  only  limitation  placed  on  the  number  of 
signals  analyzed  at  one  period  was  the  number  of  data  pods  available.  Each  data  pod 
connects  to  the  back  of  the  logic  analyzer  and  has  15  input  lines  for  a  data  signal.  One 
pod  signal  line  is  connected  to  the  system  or  master  clock.  After  all  connections  to  the 
board  are  complete,  the  logic  analyzer  is  setup  with  labels  corresponding  to  the  data  lines. 

The  logic  analyzer  is  next  set  in  one  of  two  modes  timing  or  state  analysis. 
Timing  analysis  acquires  data  and  stores  it  at  equal  time  intervals.  The  internal  clock  of 
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the  logic  analyzer  controls  the  time  interval.  State  analysis  is  acquires  data  and  stores  it 
while  a  system  is  under  test.  The  main  difference  between  the  two  is  that  the  clock  for 
the  state  mode  is  supplied  by  the  system  under  test. 

The  final  step  is  to  set  a  trigger  for  the  logic  analyzer  to  record  data  on.  The 
trigger  is  selected  by  reviewing  the  output  from  the  compilation  of  the  assembly  code. 
For  example,  in  the  ROM  assembly  language  program,  the  first  instruction  in  the  code  is 
OB  FO  00  62.  This  is  the  opcode  for  a  jump  instruction,  which  is  0000  10  in  bits  31-26. 
The  jump  address  is  formed  by  taking  bits  31-28  (OxB)  from  the  PC  and  using  the  offset 
found  in  bits  25-0  of  the  instruction,  shifting  left  by  two  to  give  bits  27-0  of  the  address. 
Thus  for  0B  F0  00  62,  the  offset  is  1 1  1111  0000  0000  0000  01 10  0010  and  shifting  left 
by  2  gives  1111  1 100  0000  0000  0001  1000  1000  or  0xFC00188.  This  is  correct  code  for 
a  “jump  start”,  where  the  start  label  is  at  BFC0  0188.  Triggering  on  this  instruction 
obtained  the  setup  of  the  processor  and  the  data  on  continuous  read/write  loop. 

1.  ROM  Read 

The  following  data  segment  is  only  a  small  portion  of  the  data  captured  with  the 
logic  analyzer.  The  board  was  setup  with  the  initial  test  program  that  read  in  the  program 
code  form  the  ROM  and  executed  a  write  cycle  of  0x00000000  to  the  KESG0  memory 
area.  The  purpose  of  the  code  was  to  verify  the  TMR  board  was  reading  program  code 
correctly  from  the  ROM. 

Following  the  data  segment  in  Table  6.1,  the  processors  start  the  bus  cycle  with 
the  assertion  of  the  read,  RD,  signal  in  label  1516.  The  A/D  bus  is  driven  with  the  voted 
address  OxADOOOOOO  and  latched  in  with  the  assertion  of  ALE  in  label  1516.  In  label 
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1517,  ALE  is  negated  allowing  the  A/D  bus  to  be  driven  by  the  voted  data  0x23080004. 
The  memory  control  asserts  is  signal  by  the  assertion  of  the  Voted  read  signal  in  label 
1517  to  assert  the  read  enable,  RDEN,  and  read  data  enable  signals.  A  single  wait  state  is 
inserted  in  the  cycle  because  of  EPROM  data  delay.  The  cycle  is  ended  with  the  negating 
of  the  read  signal  in  label  1521.  A  waveform  of  the  data  captured  by  the  logic  analyzer  of 
the  read  sequence  data  is  given  in  Figure  6.3. 


Label 

Base 

>  AD  3 1 . 0 

>  Hex 

ALE 

Bin 

RST 

Bin 

INT3 .5 
Binary 

RD 

Bi 

VOTRD  BUSERN  ACKN  DATAEN 
Binary  Binary  Bina  Binary 

1515 

AD000000 

0 

1 

100 

1 

1 

1 

1 

1 

1516 

AD000000 

1 

1 

100 

0 

1 

1 

1 

1 

1517 

1FC001A0 

0 

1 

100 

0 

0 

1 

1 

0 

1518 

ADOOOOOO 

0 

1 

100 

0 

0 

1 

1 

0 

1519 

25080004 

0 

1 

100 

0 

0 

1 

1 

0 

1520 

25080004 

0 

1 

100 

0 

0 

1 

1 

0 

1521 

25080004 

0 

1 

100 

1 

1 

1 

1 

1 

1522 

25080004 

0 

1 

100 

1 

1 

1 

1 

1 

1523 

25080004 

0 

1 

100 

1 

1 

1 

1 

1 

1524 

25080004 

0 

1 

100 

1 

1 

1 

1 

1 

1525 

25080004 

0 

1 

100 

1 

1 

1 

1 

1 

1526 

25080004 

1 

1 

100 

1 

1 

1 

1 

1 

1527 

00001050 

0 

1 

100 

1 

1 

1 

0 

1 

1528 

00000000 

0 

1 

100 

1 

1 

1 

0 

1 

1529 

00000000 

0 

1 

100 

1 

1 

1 

1 

1 

Table  6.1. A.  ROM  Data  List 


68 


Label 

Base 


>  DATAEN  BUSREQ  RDCEN  DIAGIO  MEMEN 

>  Binary  Binary  Binar  Binary  Hex 


MEMCTL 

Binary 


SYSCLK 

Hex 


1515 

1 

1 

l 

111 

AO 

0110111011110 

0 

1516 

1 

1 

l 

110 

AO 

0110111011111 

1 

1517 

0 

1 

l 

111 

AO 

0110110011110 

0 

1518 

0 

1 

l 

111 

01 

0110110011111 

1 

1519 

0 

1 

0 

111 

01 

0110110011110 

0 

1520 

0 

1 

0 

111 

00 

0110010011111 

1 

1521 

1 

1 

1 

111 

00 

0111010011110 

0 

1522 

1 

1 

1 

111 

AO 

0110111011111 

1 

1523 

1 

0 

1 

110 

AO 

0110111011110 

0 

1524 

1 

1 

1 

100 

AO  . 

0110111011111 

1 

1525 

1 

0 

1 

100 

AO 

0110111011110 

0 

1526 

1 

0 

1 

110 

AO 

0110111011111 

1 

1527 

1 

0 

1 

100 

AO 

0110101111010 

0 

1528 

1 

0 

1 

100 

El 

0010001111011 

1 

1529 

1 

0 

Table 

1  100  El 

6.I.B.  ROM  Data  List 

0011001111010 

0 

Label 

Base 

>  SYSCLK 

>  Hex 

VOTADD 

Hex 

WRITE 

Hex 

RDATAE 

Hex 

RDENN 

Hex 

CYCEND 

Hex 

RDCENN 

Hex 

EPROMCS 

Hex 

1515 

0 

006B 

1 

1 

1 

0 

1 

0 

1516 

1 

006B 

1 

1 

1 

0 

1 

0 

1517 

0 

006B 

1 

1 

1 

0 

1 

0 

1518 

1 

006B 

1 

0 

0 

1 

1 

0 

1519 

0 

006B 

1 

0 

0 

1 

1 

0 

1520 

1 

006B 

1 

0 

0 

0 

0 

0 

1521 

0 

006B 

1 

0 

0 

0 

0 

0 

1522 

1 

006B 

1 

1 

1 

0 

1 

0 

1523 

0 

0068 

1 

1 

1 

0 

1 

0 

1524 

1 

0069 

1 

1 

1 

0 

1 

0 

1525 

0 

0068 

1 

1 

1 

0 

1 

0 

1526 

1 

0416 

0 

1 

1 

0 

1 

1 

1527 

0 

0416 

0 

1 

1 

0 

1 

1 

1528 

1 

0416 

0 

1 

1 

1 

1 

1 

1529 

0 

0416 

1 

1 

1 

1 

1 

1 

Table  6. 1  .C.  ROM  Data  List 
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2.  RAM  Write 

The  purpose  of  this  program  was  to  verify  the  ram  data  write  cycle.  A  RAM  read 
was  not  possible,  because  the  RAM  segment  is  located  in  a  cache  memory  section.  The 
initialization  of  the  cache  was  not  necessary  for  this  program  execution.  This  program’s 
function  was  write  the  data  word  OxDEADBEEF  to  an  address  in  the  RAM  segment. 

The  data  sequence  in  Table  6.2  details  the  signals  during  a  RAM  write  operation. 
In  label  128,  the  processors  have  asserted  the  Write,  ALE,  RAMCS*,  and  the  A/D  bus 
with  the  address  0x000000000.  The  processor  next  negates  ALE,  latching  in  the  address. 
In  label  129,  the  A/D  bus  is  now  driven  with  the  data  OxDEADBEEF.  The  assertion  of 
the  write  signal  and  the  majority  voting  leads  to  the  assertion  of  the  voted  write  signal, 
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VOTWR.  The  memory  controller  PLD  responds  to  this  by  asserting  the  write  data 
enable,  WRDAEN,  and  acknowledge,  ACKN,  signals  in  label  129  and  130.  The 
processor  ends  the  bus  cycle  by  deasserting  write  in  label  131.  A  waveform  is  given  with 
respect  to  this  process  and  data  segment  in  Figure  6.4. 

The  data  segment  in  Table  6.2  also  confirms  the  TMR  FPGAs  executing  the 
majority  voting  properly.  During  the  code  execution  and  as  seen  below,  the  ENTCS* 
signal  remained  deasserted.  The  correct  execution  of  this  program  verifies  the  transfer  of 
data  between  components  on  the  board.  The  next  test  step  is  data  output  from  the  UART, 
which  is  presented  in  the  following  section. 


Label 

Base 

>  WRITE* 

>  Hex 

VOTEWR* 

Hex 

RDEN* 

Hex 

CYCEND* 

Hex 

RDCEN* 

Hex 

RAMCS* 

Hex 

ROM1 

Hex 

INTCS* 

Hex 

127 

1 

1 

1 

0 

1 

1 

00 

1 

128 

0 

0 

1 

1 

1 

0 

00 

1 

129 

0 

0 

1 

1 

1 

0 

00 

1 

130 

0 

0 

1 

0 

1 

0 

00 

1 

131 

1 

1 

1 

0 

1 

1 

00 

1 

132 

1 

1 

0 

1 

1 

1 

00 

1 

133 

1 

1 

0 

1 

1 

1 

00 

1 

134 

1 

1 

0 

0 

0 

1 

00 

1 

135 

1 

1 

0 

0 

0 

1 

00 

1 

136 

1 

1 

1 

0 

1 

1 

00 

1 

137 

1 

1 

1 

0 

1 

1 

00 

1 

Table  6.2.  A.  RAM  Data  List 
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Label 

Base 

>  BUSREQ 

>  Binary 

RDCEN 

Binar 

DIAG10 

Binary 

MEMEN 

Hex 

MEMCTL  J 

Binary 

SYSCLK 

Hex 

127 

0 

1 

110 

AO 

011010111110 

0 

128 

0 

1 

111 

El 

001000111111 

1 

129 

0 

1 

110 

El 

001100111110 

0 

130 

0 

1 

110 

AO 

011011111111 

1 

131 

0 

1 

110 

AO 

011011001110 

0 

132 

0 

1 

110 

01 

011011001111 

1 

133 

0 

1 

110 

01 

011011001110 

0 

134 

0 

1 

110 

00 

011001001111 

1 

135 

0 

0 

110 

00 

011101001110 

0 

136 

0 

0 

110 

AO 

011011101111 

1 

137 

0 

1 

110 

AO 

011011101110 

0 

Table  6.2.B.  RAM  Data  List 


Label 

Base 

>  AD  3 1 . 0 

>  Hex 

ALE 

Bin 

RST 

Bin 

INT3 . 5 
Binary 

RD* 

Bi 

BUSER* 

Binary 

ACK* 

Bina 

DATAE* 

Binary 

127 

25080004 

0 

1 

100 

1 

1 

1 

1 

128 

00000000 

1 

1 

100 

1 

1 

1 

1 

129 

DEADBEEF 

0 

1 

100 

1 

1 

0 

1 

130 

DEADBEEF 

0 

1 

100 

1 

1 

0 

1 

131 

DEADBEEF 

0 

1 

100 

1 

1 

1 

1 

132 

1FC001B0 

1 

1 

100 

0 

1 

1 

1 

133 

DEADBFEF 

0 

1 

100 

0 

1 

1 

0 

134 

24019FFF 

0 

1 

100 

0 

1 

1 

0 

135 

24019FFF 

0 

1 

100 

0 

1 

1 

0 

136 

24019FFF 

0 

1 

100 

0 

1 

1 

1 

137 

24019FFF 

0 

1 

100 

1 

1 

1 

1 

Table  6.2.C.  RAM  Data  List 
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100/500MH; 


z  LA  E  )  f  Waveform  1  ]  fftcq,  Control]  (cancel  ]  (  Run  ] 


Accumul ate 
Off 


Figure  6.4.  RAM  Data  Waveform 


3.  UART  DATA 

The  function  of  the  UART  program  is  to  initialize  the  UART  for  I/O  and  write  a 
continuous  data  stream  to  the  transmit  register.  This  program,  listed  in  Appendix  C, 
initializes  the  processor  in  the  exact  same  manner  as  the  two  previous  programs  but  the 
remainder  of  the  program  is  entirely  different.  The  program  first  initializes  the  16550 
UART  by  writing  data  to  the  line  control,  FIFO  control,  modem  control,  and  divisor  latch 
registers.  This  initializes  the  UART  for  eight  data  bits,  no  parity,  and  in  polling  mode. 
Next,  0x83  or  72  decimal  is  written  to  the  divisor  latch  register  for  a  baud  rate  of  9600. 
The  program  then  enters  a  continuous  write  loop  that  outputs  the  data,  0x2322223,  which 
represents  the  ASCII  character  #  to  the  transmit  register. 
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The  data  sequence  in  Table  6.3  details  the  signals  during  a  UART  write  operation. 
In  label  378,  the  processors  have  asserted  the  Write,  ALE,  and  the  A/D  bus  with  the 
address  OxlFEOOOOO.  The  processor  next  negates  ALE,  latching  in  the  address.  In  label 
379,  the  A/D  bus  is  now  driven  with  the  data  0x23222223.  The  assertion  of  the  write 
signal  and  the  majority  voting  asserts  the  voted  write  signal,  VOTWR.  The  memory 
controller  PLD  responds  to  this  by  asserting  the  write  data  enable,  WRDAEN,  and 
acknowledge,  ACKN,  signals.  The  processor  ends  the  bus  cycle  by  deasserting  write  in 
label  380.  A  waveform  is  given  with  respect  to  this  process  and  data  segment  in  Figure 
6.5. 


Additionally,  the  output  data  was  verified  by  connecting  a  PC  to  the  output  port  of 
the  UART.  The  PC  was  running  the  HyperTerminal  program  and  configured  to  match 
the  setup  characteristics  of  the  UART.  A  continuous  data  stream  of  the  ASCII  character  # 
was  outputted  to  the  screen.  The  next  step  in  the  test  sequence  is  to  receive  data  input 
from  the  PC,  modify  this  data  and  output  the  modified  data  to  the  PC.  This  program  and 


data  is  presented  in  the  next  section. 

Label  >  SYSCLK  AD31.0  ADDR32  WRITE  VOTWR  ALE  RD  VOTRD 

Base  >  Hex  Hex  Binary  Binar  Hex  Bin  Bi  Hex 


378 

1 

1FE00000 

00 

0 

0 

1 

1 

1 

379 

0 

23222223 

00 

0 

0 

0 

1 

1 

380 

1 

23222223 

00 

1 

0 

0 

1 

1 

Table  6.3. A.  UART  Data  List 

Label 

>  VOTBE  UARTCS 

WREN 

WRDAEN 

ACKN 

BURST 

RDCEN 

TIMRCS 

Base 

>  Binary 

Hex 

Hex 

Hex 

Bin 

Bin 

Bin 

Hex 

378 

0000 

0 

F 

0 

1 

1 

1 

1 

379 

0000 

0 

0 

1 

0 

1 

1 

1 

380 

0000 

0 

0 

1 

0 

1 

1 

1 

Table  6.3.B.  UART  Data  List 
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Label  >  RAMCS  UARTCS  COVTER  CYCEND  INT5.3  AVOTER  COVTER 

Base  >  Hex  Hex  Hex  Binary  Binary  Binary  Hex 


378  1001  100  0  0 

379  1000  100  0  0 

380  1010  100  1  1 

Table  6.3. C.  UART  Data  List 


Label  >  VOTINT  BUSERR 
Base  >  Hex  Binary 


378  0  1 

379  0  1 

380  0  1 

Table  6.3.D.  UART  Data  List 


f  1 00/500t1Hz  LA  E  ]  f  Haveform  1  ]  fflcq.  Control]  ^CancejJ 

{  Accumu late 
I  Off 


{  Delay 

(  tlarkers 

Acquisition  Time 

1  382 

Off 

25  Oct  2000  10:29=57 

V  J 

SYSCLK 

.  1  1  1  -  1  1  1 - 1  f 

WRITE 

1 

V0TWR 

r 

ALE 

i  . . .  r 

UARTCS 

_ i 

HRDAEN 

WREN  0 

WREN  1 

WREN  2 

WREN  3 

ACKN 

Figure  6.5.  UART  Data  Waveform 
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4.  UART  INPUT/OUTPUT 


The  purpose  of  the  UART  I/O  program  was  to  test  the  board  read  cycle  and 
storage  of  data  input.  This  program  read  in  data  from  the  UART  receive  register,  added 
30  to  this  data,  and  transmitted  this  data  back  to  the  PC.  This  program  differed  from  the 
previous  UART  code  in  the  setup  of  the  UART.  Specifically,  the  modem  control  register 
was  loaded  with  0x23,  which  set  the  UART  in  Autoflow  control  mode.  The  Autoflow 
control  mode  enabled  to  UART  to  control  the  Request  to  Send  (RTS)  and  Clear  to  Send 
(CTS)  signals.  This  change  was  implemented  to  enable  the  program  to  output  individual 
characters. 

The  program  indicates  it  is  running  by  outputting  the  ACS13  character  #  to  the  PC. 
Then  entered  a  loop,  which  checked  the  status  register  receive  data  bit.  The  assertion  of 
this  bit  informed  the  UART  that  the  receive  register  held  one  byte.  The  data  that  was  read 
in  is  stored  in  the  T7  register  and  30  added  to  this  quantity.  The  addition  of  30  changed 
the  uppercase  ASCII  character  to  a  lower  case  character.  The  contents  of  register  T7  is 
then  transmitted  to  the  PC. 

The  data  sequence  in  Table  6.4  details  the  signals  during  the  read  in  and  output  of 
the  data.  In  label  18,  the  processors  have  asserted  the  Read,  ALE,  UARTCS*,  and  the 
A/D  bus  with  the  receive  register  address  OxlFEOOOOO.  The  processor  next  negates  ALE, 
latching  in  the  address.  In  label  19,  the  A/D  bus  is  now  driven  with  the  input  data 
0x00000054.  This  data  is  then  stored  in  the  register  T7. 
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Label 

>  AD3 1 . 0 

ADDR32 

ALE 

SYSCLK 

BUSERN 

RD 

VOTRD 

RDEN 

Base 

>  Hex 

Binary 

Bin 

Decima 

Binary 

Bi 

Hex 

Hex 

18 

1FE00000 

00 

1 

1 

1 

0 

0 

0 

19 

00000054 

00 

0 

0 

1 

0 

0 

0 

20 

00000054 

00 

0 

1 

1 

0 

0 

0 

21 

00000000 

00 

0 

0 

1 

1 

1 

1 

Table  6.4.A.  UART  Receive  Data 

Label 

Base 

>  WRITE 

>  Binar 

WREN 

Hex 

VOTWR 

Hex 

VOTRD 

Hex 

WREN 

Hex 

ACKN 

Bina 

CYCEND 

Binary 

INT5 . 3 
Binary 

18 

1 

0 

0 

0 

0 

1 

0 

100 

19 

1 

F 

1 

0 

F 

1 

0 

100 

20 

1 

F 

0 

0 

F 

1 

0 

100 

21 

1 

F 

1 

1 

F 

1 

1 

100 

Table  6.4.B.  UART  Receive  Data 

Label 

>  TIMRCS 

EPROCS 

RAMCS 

UARTCS 

COVTER 

AVOTER 

VOTINT 

Base 

>  Hex 

Hex 

Hex 

Hex 

Hex 

Binary 

Hex 

18 

1 

1 

1 

0 

0 

0 

0 

19 

1 

1 

1 

0 

0 

0 

0 

20 

1 

1 

1 

0 

0 

0 

0 

21 

1 

1 

1 

0 

0 

0 

0 

Table  6.4.C.  UART  Receive  Data 


The  data  sequence  in  Table  6.5  details  the  signals  during  the  output  of  the 
modified  data.  In  label  194,  the  processors  have  asserted  the  Write,  ALE,  UARTCS*, 
and  the  A/D  bus  with  the  transmit  register  address  OxlFEOOOOO.  The  processor  next 
negates  ALE,  latching  in  the  address.  In  label  195,  the  A/D  bus  is  now  driven  with  the 
modified  input  data  0x00000074.  This  data  is  written  to  the  UART,  which  then  outputs 
the  data  on  the  serial  output  port. 
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Label  >  AD31.0  ADDR32  ALE  SYSCLK  BUSERN  RD  VOTRD  RDEN 

Base  >  Hex  Binary  Bin  Decima  Binary  Bi  Hex  Hex 


194 

1FEOOOOO 

00 

1 

1 

1  1 

1 

1 

195 

00000074 

00 

0 

0 

1  1 

1 

1 

196 

00000074 

00 

0 

1 

1  1 

1 

1 

197 

00000200 

00 

0 

0 

1  1 

1 

1 

Table  6.5. A.  UART  Transmit  Data 

Label 

Base 

>  WRITE 

>  Binar 

WREN 

Hex 

VOTWR  VOTRD 
Hex  Hex 

WREN 

Hex 

ACKN 

Bina 

CYCEND 

Binary 

INT5 . 3 
Binary 

194 

0 

F 

0 

1 

F 

1 

0 

100 

195 

0 

0 

0 

1 

0 

0 

0 

100 

196 

0 

0 

0 

1 

0 

0 

0 

100 

197 

1 

F 

1 

1 

F 

1 

1 

100 

Table  6.5. B. 

UART  Transmit  Data 

Label 

>  TIMRCS 

EPROCS 

RAMCS 

UARTCS 

COVTER 

AVOTER 

VOTINT 

Base 

>  Hex 

Hex 

Hex 

Hex 

Hex 

Binary 

Hex 

194 

1 

1 

1 

0 

0 

0 

0 

195 

1 

1 

1 

0 

0 

0 

0 

196 

1 

1 

1 

0 

0 

0 

0 

197 

1 

1 

1 

0 

0 

0 

0 

Table  6.5.C.  UART  Transmit  Data 


This  chapter  presented  the  data  captured  during  program  execution.  This  data 
supports  the  implementation  of  the  TMR  design.  The  goal  of  the  design  is  the  utilization 
of  COTS  devices  in  space  applications.  In  support  of  this  effort,  the  next  chapter 
discusses  preliminary  design  considerations  for  a  space  flight  board. 
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VII.  CONVERSION  TO  SPACE  FLIGHT  BOARD 

Once  the  testbed  has  been  designed,  implemented,  and  evaluated,  the  next  logical 
step  in  the  evolution  of  the  TMR  design  is  conversion  to  a  space  flight  board.  The 
conversion  of  the  design  depends  on  numerous  factors,  such  as  determination  of  parts  to 
be  replaced,  size  and  power  constraints  just  to  name  a  few.  The  following  sections  will 
discuss  issues  that  deal  with  the  preparation  of  the  TMR  board  for  space  applications. 
The  focus  of  the  design  for  the  TMR  board  is  with  respect  to  the  next  satellite,  NPSAT1, 
being  designed  and  built  by  the  Naval  Postgraduate  School.  This  satellite  design 
constrains  the  power,  weight  and  size  for  the  TMR  design. 

A.  CONSTRAINTS  AND  TRADEOFFS 

Every  satellite  design  conducts  studies  on  the  tradeoffs  between  different  system 
designs.  The  following  sections  contain  an  overview  of  the  design  constraints  and 
tradeoffs  of  the  TMR  design  for  a  space  flight  board. 

1.  Power 

Power  is  a  precious  commodity  in  space.  A  satellite  is  limited  in  the  power  that  it 
has  available  by  the  sizes  of  the  solar  array  and  batteries.  The  TMR  design  inherently 
increases  the  power  required  compared  to  a  normal  processor  board.  The  implementation 
of  this  design  in  space  applications  has  to  balance  the  performance  and  reliability  against 
with  the  increased  power  consumption.  The  current  system  design  utilizes  low  power 
consumption  commercial  parts.  The  conversion  of  this  board  to  a  flight  ready  design  may 
require  the  use  of  radiation  hardened  (radhard)  components.  A  radiation-hardened 
component  is  designed  to  continue  functioning  when  exposed  to  high  levels  of  radiation 
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over  the  lifetime  of  the  device.  For  example,  most  radiation-hardened  components  are 
designed  to  continue  operating  to  a  total  radiation  dosage  of  20  Krads.  Thus,  the  device 
can  sustain  a  dosage  of  four  Krads  per  year  for  a  period  of  5  years.  Though  the  TMR 
design  is  robust  and  does  not  allow  errors  to  propagate  past  the  processor,  certain  devices 
that  implement  the  design  require  increased  tolerance.  For  example,  the  FPGA  contains 
the  voting  logic;  these  devices  reliability  has  to  be  as  close  to  100  percent  as  possible. 
Their  failure  would  cause  a  breakdown  of  the  TMR  design  and  lead  to  a  total  system  loss. 
The  decision  on  which  parts  will  be  radhard  will  depend  on  the  role  of  the  device,  the 
power  capability  of  the  spacecraft  and  the  life  of  the  satellite.  Radhard  components 
generally  require  more  power  than  their  non-hardened  counterparts  do.  The  TMR  design 
with  non-radhard  devices  currently  has  power  consumption  between  6.5  to  9.5  Watts 
depending  on  the  function  of  the  board.  The  predicted  maximum  power  available  for 
NPSAT1  is  22  Watts.  These  factors  go  into  the  decision  model  for  selecting  devices  to 
utilize  in  the  design. 

2.  Size 

The  small  size  of  NPSAT1  limits  the  area  available  for  the  TMR  designed  board. 
The  current  size  of  the  TMR  board  is  13x12  inches.  In  researching  the  constraints  placed 
on  designs  used  in  the  previous  Petite  Amateur  Satellite  (PANSAT),  it  was  discovered 
this  board  was  too  large.  Boards  previously  utilized  in  the  PANSAT  design  were  on 
average  were  6x4  inches.  The  solution  to  this  is  to  section  the  board  into  multiple  smaller 
boards  interconnected  by  bus  connectors.  In  inspecting  the  current  TMR  design,  two 
alternatives  were  thought  of  for  sectioning  the  board.  The  first  alternative  is  to  group  the 
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components  on  boards  by  like  device.  For  example,  one  board  would  hold  all  three 
processors  and  another  would  hold  all  FIFOs.  The  second  alternative  is  to  section  the 
design  by  breaking  the  TMR  design  into  individual  component  boards.  An  example  of 
this  is  that  one  board  would  contain  an  all  the  RAM/ROM.  The  second  option  is  by  far 
the  most  efficient  choice  for  two  reasons.  These  reasons  are  design  production  efficiency 
and  testing.  The  design  engineer  would  only  need  to  design  the  three  identical  processor 
boards  and  one  assorted  component  board.  This  option  would  aid  in  testing  by  allowing 
each  processor  board  to  function  alone  for  testing. 

Figure  7.1  depicts  one  possible  configuration  for  the  boards.  The  processors  and 
latches  would  be  on  one  card,  the  memory,  ROM  and  RAM,  on  another  card.  The 
Oscillators  or  clocks,  the  interrupt  circuit,  and  PLD  logic  would  be  placed  together.  The 
last  card  would  contain  all  three  FPGAs  and  the  Serial  EEPROM. 
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Figure  7.1.  Space  Design  Layout 

3.  Vibration  Analysis 

A  design  to  be  utilized  for  space  applications  has  to  be  tolerant  of  the  severe 
shocks  and  vibrations  experienced  during  launch.  During  launch  into  orbit,  the  body  of 
the  satellite  experiences  gravitational  forces  up  to  9G.  Once  in  space,  the  vehicle  will  the 
experience  the  shock  of  being  released  by  an  explosive  bolt.  Loss  of  connectivity  as  a 
result  of  such  vibrations  is  avoidable  with  proper  testing.  The  NPS  Space  Academic 
Group  has  the  capability  to  conduct  this  testing  dependent  on  the  launch  vehicle.  In 
inspecting  the  board  for  possible  problems,  an  immediate  source  of  concern  is  the  surface 
mounted  FPGA.  The  FPGA  are  secured  to  board  by  only  the  soldered  pins. 
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B.  SPACE  FLIGHT  PREPARATION 


The  preparation  of  a  satellite  for  space  is  filled  with  numerous  questions.  When 
will  the  mission  fly?  Where  will  the  mission  fly?  What  systems  are  critical?  What  amount 
of  shielding  will  be  around  the  SEE  devices?  In  addition,  what  is  the  mission  life?  All  of 
these  factors  are  critical  in  the  selection  of  devices  for  a  spacecraft  and  lead  to  a 
prediction  of  the  radiation  environment  of  a  mission.  The  purpose  of  this  section  is  to 
discuss  some  of  the  factors  in  the  selection  of  components  and  design  criteria. 

1.  Mission  Parameters 

As  discussed  in  the  background,  the  orbital  parameters  of  a  satellite  decide  the 
radiation  environment  it  will  experience.  This  in  turn  impacts  numerous  factors  in  the 
satellite  design  such  as  shielding  thickness.  The  TMR  system  is  destined  to  be  a  part  of 
the  next  Naval  Postgraduate  School  Satellite  design.  Preliminary  orbital  parameters  for 
this  satellite  place  it  at  an  altitude  of  800km,  which  is  a  Low  Earth  Orbit  (LEO).  The 
harshest  radiation  environment  encountered  by  satellites  in  a  LEO  is  the  high-energy 
particles  of  the  Van  Allen  Belt,  which  it  will  pass  through  numerous  times  each  day.  The 
energies  of  the  protons  in  the  belts  can  range  from  KeV  to  hundreds  of  MeV.  The  level 
of  radiation  flux  experienced  during  of  a  satellite’s  life  in  the  belt  varies  greatly  with  orbit 
inclination  and  altitude.  Flux  is  the  flow  of  energy  per  unit  time  and  per  unit  cross- 
sectional  area.  At  altitudes  between  200  and  600-Km  large  increases  in  radiation  flux 
levels  are  seen  as  the  altitude  increases.  Above  600  Km,  the  radiation  flux  increases 
more  gradually  as  altitude  increases. 
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A  LEO  satellite,  though  subjected  to  the  Van  Allan  belt,  experiences  a  benefit 
from  its  lower  altitude,  which  is  somewhat  protected  from  cosmic  rays  and  solar  flares  by 
the  earth’s  magnetic  field.  As  the  satellite  altitude  increases,  the  protection  from  these 
particles  decreases.  The  amount  of  protection  the  satellite  receives  from  the  earth’s 
magnetic  field  is  also  dependent  on  inclination.  As  the  inclination  of  the  satellite 
increases  above  45  degrees,  the  satellite  orbit  enters  the  Polar  Regions  more  frequently, 
which  is  beyond  the  magnetic  field  exposing  it  to  the  full  effect  of  space  radiation. 
Utilizing  this  information,  a  Radiation  Effects  Engineer  is  able  to  proceed  to  the  next  step 
in  part  selection,  which  is  a  radiation  risk  assessment. 

2.  Radiation  Risk  Assessment 

A  radiation  risk  assessment  for  any  electronic  components  consists  of  the 
calculation  of  total  dose  damage  and  SEU  susceptibility  of  the  device  caused  by  the 
predicted  radiation  environment  of  the  spacecraft. 

Knowing  the  orbit  parameters  allows  the  determination  of  the  suitability  of 
electronic  devices  in  their  intended  application,  dependent  on  the  radiation  environment 
to  which  the  devices  are  subjected.  Utilizing  an  altitude  of  800  KM  alone,  a  satellite  will 
experience  a  predicted  radiation  dose  (called  ionizing  dose)  rate  of  approximately  one 
krad  (Si)  per  year.  [Ref.  14] 

An  additional  method  available  to  predict  the  environment  is  the  use  of  software 
radiation  environmental  simulations.  There  are  multiple  software  programs  available  for 
the  prediction  of  the  SEE  effects  such  as  SpaceRad  and  Cosmic  Ray  Effects  on  Micro- 
Electronics  (CREME96).  SpaceRad  is  a  commercial  program  and  a  demonstration 
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version  was  unavailable  for  evaluation.  CREME96  is  a  free  program  available  at  the 
Naval  Research  Laboratory  website.  This  program  focuses  on  the  prediction  of  the  Single 
Event  Effects  and  determining  SEU  rates,  but  to  accomplish  this  requires  radiation 
ground-test  data  on  the  devices.  This  software  was  utilized  primarily  to  get  a  picture  of 
the  environment  that  the  spacecraft  would  be  exposed  to  as  a  prelude  to  assist  in  device 
selection. 

CREME  requires  the  user  to  input  the  orbit  of  the  satellite  and  select  the 
environment,  either  quiescent  or  extreme  solar  events.  This  information  is  entered  in  a 
User  Request  file.  The  orbital  profile  entered  into  the  user  request  file  an  inclination  of  30 
degrees  and  at  a  perigee/apogee  of  450  km.  Figure  7.2  depicts  fluxes  of  various  elements, 
atomic  number  Z=1  (protons)  to  atomic  number  Z=8  (oxygen),  vs.  kinetic  energy.  For 
example,  using  atomic  number  7  (nitrogen)  and  breaking  this  element  into  species  based 
on  kinetic  energy.  Then  using  the  figure,  the  spacecraft  would  experience  a  flux  of  10'6 
from  nitrogen  elements  with  a  kinetic  energy  of  1  MeV/nucleon.  This  allows  an 
evaluation  of  the  ionizing  radiation  environment  of  different  elements  at  the  external 
surface  of  the  spacecraft  for  the  orbital  parameters  specified.  The  recommendation  for 
SEE  calculations  is  to  consider  elements  up  to  atomic  number  92.  This  was  not  done  due 
to  the  complexity  of  the  figure.  With  this  information,  the  user  has  the  ability  to 
determine  the  amount  of  shielding  required  to  protect  the  spacecraft.  This  will  give  a 
jump  off  point  for  calculating  SEU  on  different  devices. 


85 


Figure  7.2.  Differential  Flux  of  various  elements  vs.  Kinetic  Energy  at  the  external  surface 
of  the  spacecraft  Z=1  (protons)  Z=8  (Oxygen) 

3.  Mission  Specific 

After  mission  planners  and  radiation  effects  engineers  have  planned  the  orbit 
configuration,  date  of  launch,  mission  life,  and  nominal  shield  thickness,  an  analysis 
utilizing  this  data  is  performed.  The  first  phase  of  this  analysis  is  to  decide  on  the  SEU 
requirement  determined  by  the  function  of  the  device.  The  role  of  the  device  in  the  system 
is  critical  to  the  analyses.  The  application  of  this  process  to  the  TMR  system  is  vital.  The 
following  sections  will  discuss  design  approaches  that  can  be  used  to  increase  radiation 
hardness  and  tolerance  of  the  system  to  SEU. 
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a)  Microprocessor 

First  and  foremost  in  the  design  are  the  three  IDT3081  microprocessors. 
The  microprocessor  is  the  brain  of  the  entire  design  and  its  correct  function  is  essential. 
Though,  the  TMR  voting  scheme  protects  the  system  from  a  propagating  fault  additional 
protection  is  necessary  to  increase  system  reliability.  Previous  radiation  testing 
conducted  on  the  IDT3081  concluded  that  the  R3000  microprocessor  could  survive  the 
proton  SEU  environment.  [Ref.  15]  Later  testing  of  the  IDT3081  predicted  a  proton 
upset  rate  per  device  of  1.4xl0~4  upsets/day  with  60  mils  of  aluminum  shielding.  [Ref.  16] 
The  function  of  the  TMR  system  would  be  degraded  considerably  if  a 
processor  ceased  functioning.  In  theory,  if  the  other  two  processors  still  concur  the 
system  would  continue  functioning  properly.  However,  if  the  two  processors  disagree 
and  cause  a  voter  interrupt,  the  system  would  be  unable  to  determine  the  correct  data. 
The  implementation  of  a  watchdog  program  in  the  operating  system  of  the 
microprocessor  is  therefore  essential.  The  watchdog  timer  is  like  an  “I’m  functioning” 
method  of  error  control.  If  this  message  is  not  received  within  a  certain  period  of  time,  a 
“time  out”  has  occurred.  The  system  will  then  perform  some  action  such  as  a  reset. 

An  additional  method  that  can  be  implemented  to  increase  system 
reliability  is  the  filling  of  unused  RAM  with  software  interrupts  instructions.  These 
instructions  would  cause  a  graceful  recovery  if  the  processor  jumped  outside  the 
programmed  memory  area. 
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b)  XILINXFPGA 

The  next  major  device  section  in  the  TMR  design  is  the  voters  and  system 
controller  FPGA.  As  stated  earlier,  the  voter  is  the  single  point  of  failure  in  a  TMR 
system.  An  error  in  these  devices  would  lead  to  faults  permeating  throughout  the  system. 
The  system  controller  performs  the  essential  role  of  managing  communication  and 
transfer  of  information.  A  possible  error  here  is  not  as  detrimental  as  in  the  voters,  but 
the  communication  function  of  this  device  is  vital.  The  role  of  these  devices  in  the  design 
calls  for  any  and  all  protection.  Therefore,  the  use  of  radiation-hardened  components  is 
necessary  and  their  use  is  seen  as  an  essential  cornerstone  to  the  success  of  this  design. 

One  of  the  key  features  of  FPGAs  is  that  they  are  reconfigurable.  If  a 
design  change  is  necessary  during  flight,  then  a  new  configuration  can  be  loaded  and  the 
functionality  of  the  FPGA  altered  without  having  physical  access.  Unfortunately,  this 
increased  flexibility  results  in  a  more  involved  designed  solution  for  SEU  effects. 

The  straightforward  approach  to  SEU  mitigation  is  to  reconfigure  the 
FPGA  upon  detecting  a  system  error  or  at  specific  time  intervals.  For  example,  an  FPGA 
utilized  to  control  a  spacecraft  thermal  control  system  experiences  an  SEU,  causing  the 
FPGA  to  turn  on  the  heater.  If  through  onboard  systems  it  can  be  determined  the  heater  is 
on  inadvertently,  a  command  could  be  sent  to  reconfigure  the  FPGA. 

A  second  approach  that  can  be  utilized  is  the  readback  function.  This 
feature  allows  the  reading  of  the  state  of  every  flip-flop  and  configuration  cell  within  the 
FPGA.  This  is  a  capability  provided  by  the  Xilinx  FPGA.  This  function  runs  in  the 
background  and  does  not  affect  the  function  of  the  FPGA.  A  CRC  checksum  calculated 
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from  the  readback  bits  is  generated  and  inserted  at  the  end  of  the  bit  stream.  The 
checksum  is  then  compared  to  the  expected  checksum  for  the  current  configuration,  if  it 
does  not  match,  then  an  error  has  occurred.  [Ref.  17] 

c)  Memory 

The  memory  system  is  the  next  portion  of  the  TMR  design.  This  memory 
system  discussion  includes  both  RAM  and  ROM.  The  validity  of  memory  in  any 
computer  system  is  of  major  concern.  It  stores  and  provides  the  data  necessary  for  proper 
functioning.  There  are  some  protections  that  can  be  implemented  to  the  memory  system 
to  increase  reliability.  The  first  would  of  course  be  an  upgrade  to  a  radiation-hardened 
component.  Possible  choices  for  replacement  devices  are  given  in  a  later  section.  The 
second  is  the  addition  of  an  Error  Detection  and  Correction  (EDAC)  scheme  such  as 
parity  error  or  hamming  code,  which  can  be  added  to  the  overall  system  design.  The 
addition  of  EDAC  can  be  accomplished  in  both  software  and  hardware.  The  focus  of  the 
following  will  be  on  hardware  EDAC.  Keep  in  mind  the  following  is  discussed  only  to 
increase  the  overall  reliability  of  the  spacecraft.  The  TMR  design  is  itself  an  Error 
Detection  and  Correction  method.  The  voting  modules  detect  the  error  by  the  majority 
vote  and  the  error  is  corrected  by  only  allowing  the  voted  data  pass. 

EDAC  is  accomplished  by  the  use  of  algorithms  such  as  the  Hamming 
Code.  The  Hamming  code  is  suitable  for  detecting  single  errors  in  a  code.  It  functions  by 
encoding  a  block  data  with  check  code.  The  code  is  then  check  by  the  next  unit  and  is 
able  to  detect  the  position  of  a  single  error  and  the  existence  of  more  than  one  error.  By 
the  determination  of  the  position  of  the  error,  it  is  then  possible  to  correct  that  error.  The 
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level  of  EDAC  protection  desired  determines  the  number  of  check  word  bits  per  data 
word.  For  example,  providing  single  bit  error  correction  with  dual  bit  error  detection  to 
eight  to  fifteen  data  bit  requires  five  check  bits. 

An  EDAC  IC  functions  by  storing  a  check  word  in  memory  with  the  data 
word.  During  a  read  operation,  the  data  word  and  corresponding  check  word  are  retrieved 
from  memory.  The  EDAC  IC  generates  a  new  check  word  determined  by  the  data  from 
memory  and  compares  it  to  the  check  word  stored  in  memory.  If  the  two  check  words  are 
identical,  the  data  word  is  correct.  If  the  check  words  are  different,  an  error  has  been 
detected.  Single-bit  error  corrections  with  dual-bit  error  detection  ICs  are  available 
commercially.  The  placing  of  an  EDAC  component  on  the  bus  lines  from  the  memory 
would  force  all  data  used  by  the  microprocessor  to  pass  through  this  device. 

Another  method  of  hardware  EDAC  that  is  quite  common  is  parity. 
Parity,  being  a  single  bit  at  the  end  of  a  structure,  simply  indicates  whether  an  odd 
number  or  an  even  number  of  ones  was  in  that  structure.  This  method  detects  an  error  if 
an  odd  number  of  bits  are  in  error,  but  if  an  even  number  of  errors  occurs,  the  parity  is 
still  correct.  For  example,  the  parity  is  the  same  whether  zero  or  two  errors  occur. 
Additionally,  notice  that  this  is  a  detect-only  method  of  mitigation  and  does  not  attempt 
to  correct  the  error.  Therefore,  an  additional  algorithm,  such  as  Manchester-encoding,  is 
also  utilized.  This  encoding  detects  if  the  data  is  in  the  proper  format.  Parity 
generator/checker  ICs  are  commercially  available. 

These  EDAC  methods,  such  as  the  Hamming  code,  are  more  efficient  than 
TMR.  They  do  have  a  downfall,  which  is  they  are  very  hardware  intensive.  For 
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example,  the  addition  of  an  EDAC  IC  to  the  TMR  design  would  introduce  seven  bits  of 
additional  data  for  each  32  bits  of  data.  This  would  in  turn  require  additional  memory 
hardware  components  be  added  to  the  design  to  store  this  additional  data. 

d)  Serial  EEPROM 

The  serial  EEPROM  is  in  a  separate  category  from  the  other  memory 
devices.  The  EEPROM  is  utilized  only  in  the  programming  of  the  FPGA.  The 
programming  of  a  device  in  space  is  problematic,  increasing  the  chance  of  error  in  the 
program.  As  shown  in  the  following  section  no  radiation  data  was  found  on  serial 
EEPROM.  A  small  cross-section  and  susceptibility  to  SEU  limit  their  use  in  space.  The 
removal  of  this  part  and  one  time  programming  of  the  FPGA  defeats  the  purpose  of 
utilizing  an  FPGA. 

An  alternative  that  needs  to  be  discussed  is  use  of  ASIC  designs  for  a 
satellite.  Programmable  logic  has  the  advantage  over  the  ASIC  in  reduced  cost  and  faster 
design  time.  The  use  of  an  ASIC  also  defeats  the  purpose  of  using  a  FPGA,  the  benefit  of 
allowing  on-orbit  design  changes.  This  flexibility  allows  a  mission  to  adapt  to  changing 
requirements. 

e)  FIFO 

The  FIFOs  in  the  TMR  design  are  grouped  into  three  banks  of  five  for 
each  microprocessor.  The  need  for  the  FIFOs  in  a  space  flight  board  depends  on  the 
function  of  the  board.  If  the  desire  is  to  later  analyze  data  to  discover  the  location  of  the 
fault  then  FIFOs  are  necessary.  If  on  the  other  hand,  the  desire  is  to  put  a  functional 
system  board  and  not  analyze  the  data,  but  just  the  performance  of  the  system  in  response 
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to  faults  then  the  FIFOs  can  be  removed.  The  FIFOs’  only  function  is  the  collection  and 
transfer  of  data  after  a  vote  interrupt.  Therefore,  the  device  performs  an  important  but  not 
essential  analytical  function.  The  current  FIFOs  are  1024X8,  which  is  a  common  size  for 
a  bus.  A  design  change  that  would  improve  reliability  is  the  changing  of  these  devices  to 
9-bit  wide  ICs.  This  ninth  bit  would  enable  the  use  of  parity  thus  enabling  detection  of 
single  bit  errors. 

f)  Assorted 

The  remaining  components  on  the  board  consist  of  address  latches  and 
buffer/drives.  These  components  play  an  important  role  in  any  design.  There  is  enough 
current  data  on  the  non-radiation  hardened  components  provided  in  Appendix  D  that  use 
is  justified.  The  oscillators  are  the  only  remaining  component  not  touched  upon  in  the 
previous  sections.  The  use  of  a  radiation  tolerant  oscillator  is  not  only  recommended  but 
also  necessary  for  the  design.  The  clock  signal  is  the  most  important  signal  in  the  entire 
design.  It  synchronizes  the  voters  and  provides  a  reference  signal  to  the  processors. 

C.  PART  SELECTION 

The  next  step  in  the  transition  process  is  to  take  the  components  list  and  search  for 
radiation  testing  data  on  the  devices.  There  are  numerous  Radiation  Data  Banks  on  the 
Internet  for  example  ERRIC/DASIAC  and  the  Goddard  Space  Flight  Center  both 
maintain  radiation  test  lists.  In  searching  for  the  devices  or  compatible  devices  to  limit 
design  changes,  the  information  at  these  databases  was  lacking.  None  of  the  devices 
utilized  in  the  design  and  very  few  comparable  devices  were  found.  The  earliest  database 
entries  that  were  found  on  device  testing  is  1997  and  that  was  on  devices  manufactured 
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two  to  three  years  previously.  This  information  offered  little  assistance  in  device 
selection. 

Next  in  the  process  was  a  search  for  radiation-hardened  devices  at  companies  such 
as  UTMC  and  Honeywell.  To  qualify  as  a  radiation-hardened  device  the  manufacture  has 
to  guarantee  operation  at  20  krad.  Hardness  is  simply  a  measure  of  the  total  dose  of 
radiation  to  which  an  IC  can  be  subjected  before  critical  parameters  cross  a  predefined 
threshold. 

The  designer  has  to  keep  in  mind  the  most  cost  efficient  method  for  meeting  the 
SEU  requirement  is  to  make  an  appropriate  combination  of  SEU-hard  devices  and  other 
factors.  The  radiation  devices  though  meeting  mission  parameters  for  radiation  tolerance 
consume  a  large  portion  of  energy.  Appendix  D  gives  a  part  breakdown  of  available 
radiation  hardened  compatible  devices  and  their  cost.  It  additionally  lists  suitable  COTS 
devices  and  the  radiation  testing  data  available  on  the  device. 
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VIII.  CONCLUSIONS  AND  FOLLOW-ON  RESEARCH 

The  previous  chapter  provided  preliminary  design  considerations  for  a  space  flight 
design.  This  chapter  will  present  the  conclusion  drawn  from  the  project  and  areas  for 
follow-on  work. 

A.  CONCLUSIONS 

During  this  project,  a  fabricated  TMR  board  design  was  modified,  finished  and 
tested.  The  design  was  expanded  with  the  addition  of  a  voltage  regulator  for  the  FPGAs. 
The  UART  was  swapped  for  a  newer  version.  The  programming  and  addition  of  the 
system  controller  to  the  design  enables  the  system  to  transfer  data  to  the  HCI.  Burning 
programs  into  the  ROM  devices  and  capturing  execution  data  on  a  digital  logic  analyzer 
tested  the  design.  Finally,  the  research  focused  on  the  preliminary  design  requirements 
for  a  space  flight  board. 

The  data  captured  by  the  logic  analyzer  and  presented  in  Chapter  V  demonstrated 
the  conceptual  and  hardware  implementation  of  the  TMR  concept  to  be  valid.  The 
measured  waveforms  agreed  with  the  predicted  waveforms  presented  in  Reference  2. 
This  research  advanced  the  project  by  correcting  and  completing  the  hardware  design, 
designing  and  executing  test  programs,  and  verifying  the  design  worked  as  anticipated. 

B.  FOLLOW-ON  RESEARCH 

The  advancement  of  this  project  one  step  further  creates  additional  paths  of 
follow-on  research.  This  section  discusses  some  of  the  areas  where  follow-on  research  is 
recommend. 


95 


1.  Completion  of  TMR  Implementation 

Given  that  the  hardware  is  completed,  the  system  is  ready  for  software  integration, 
which  consists  of  two  parts,  the  O/S  and  the  HCI,  which  are  detailed  in  Ref.  3.  The 
VxWorks  O/S  previously  constructed  requires  testing  and  installation  onto  the  EPROMs. 
The  TMR  system  would  next  be  connected  to  a  computer  running  the  HCI.  The 
implementation  of  the  HCI  will  communicate  to  the  TMR  board  via  two  serial  cables. 
The  handshaking  between  the  HCI  and  hardware  needs  to  be  tested  to  ensure  the 
communication  paths  are  operating  accurately  and  the  data  format  being  transmitted  is 
correct.  When  these  objectives  are  fulfilled,  the  system  will  be  a  fully  functional  TMR 
system  that  is  able  to  detect  and  correct  single  errors  in  any  of  the  processors  and  provide 
the  data  corresponding  to  that  error  to  the  HCI  for  analysis.  The  TMR  system  is  then  set 
for  radiation  testing  and  modifications  for  other  uses. 

2.  Radiation  Testing 

The  completion  of  the  software  and  hardware  integration  will  lead  to  the  radiation 
testing  of  the  design.  This  testing  will  investigate  the  survivability  of  the  COTS  devices 
utilized  on  the  board  and  the  ability  of  the  design  to  handle  SEUs.  The  test  facility  that 
will  most  likely  be  utilized  for  this  is  the  cyclotron  at  the  University  of  California  at 
Davis.  Additionally,  the  Naval  Research  Laboratory  will  allow  utilization  of  a  laser  to 
implement  SEU.  The  laser  requires  exact  precision  to  impact  registers  on  the  devices 
tested. 
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APPENDIX  A  UPDATED  TMR  PLD  FILES 


Name  MemCont ; 

PartNo  ATF22V10C-7PC  ; 

Created  Date  5/27/00 ; 

Revision  02  ; 

Designer  David  Summers  ; 

Modified  by  Damen  Hofheinz; 

Company  NPS  ; 

Assembly  TMR  R3081  ; 

Location  U54  ; 

Device  g22vl0 ; 

j*  ^i^*********************  INPUT  PINS  **************************/ 

PIN  1  =  SYSCLK;  /*  SYSCLK  FR  CPUA  */ 

PIN  2  =  INTCSN;  /*  INTERRUPT  CHIP  SELECT  */ 

PIN  3  =  RAMCSN;  /*  SRAM  CHIP  SELECT  */ 

PIN  4  =  TIMERCSN;  /*  TIMER  CHIP  SELECT  */ 

PIN  5  =  UARTCSN;  /*  UART  CHIP  SELECT  */ 

PIN  6  =  EPROMCSN;  /*  EPROM  CHIP  SELECT  */ 

PIN  7  =  VOTBURSTN;  /*  VOTED  BURST  READIWRITE  NEAR  */ 

PIN  8  =  VOTRDN;  /*  VOTED  READ  */ 

PIN  9  =  VOTWRN;  /*  VOTED  WRITE  */ 

PIN  10  =  CVOTERR;  /*  CONTROL  VOTER  ERROR  */ 

PIN  1 1  =  DVOTERR;  /*  DATA  VOTER  ERROR  */ 

PIN  13  =  RESETN;  /*  SYNCHRONOUS  SYSTEM  RESET  */ 

PIN  19  =  AVOTERR;  /*  ADDRESS  VOTER  ERROR  */ 

y*  ^5^*********************  OUTPUT  PINS  *************************/ 

PIN  [14,15,16,17]  =  [COUNT3..0];  /*  WAIT  STATE  GENERATOR  */ 

PIN  18  =  CYCENDN;  /*  CYCLE  END  SIGNAL  */ 

PIN  20  =  BUSERRN;  /*  BUS  ERROR  SIGNAL  TO  CPU  */ 

PIN  21  =  ACKN;  /*  ACK  SIGNAL  TO  CPU  */ 

PIN  22  =  RDCENN;  /*  READ  CLOCK  ENABLE  TO  CPU  */ 

PIN  23  =  VOTINTN;  /*  VOTER  INTERRUPT  TO  CPU  */ 

/*******************  CONSTANT  DEFINITIONS  *******************/ 

$DEFENE  LOW  T3X) 

SDEFINE  HIGH  BT 
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/**********************  LOGIC  EQUATIONS  ************************/ 


/*  */ 

P  WAIT  STATE  COUNTER  COUNT[3..0]  */ 

/*  */ 

PTHE  PURPOSE  OF  THE  WAIT  STATE  COUNTER  IS  TO  PROVIDE  */ 

PREFERENCE  FOR  THE  MEMORY  CONTROLLER  SIGNALS.  IT  */ 

PSTARTS  COUNTING  WHEN  A  READ  OR  WRITE  CYCLE  IS  INITIATED  */ 
PAND  RESETS  WHEN  THERE  IS  A  RESET  OR  CYCLE  ENDSIGNAL.  */ 
PTHE  COUNTER  USES  THE  SYSCLK  AS  ITS  REFERENCE  CLOCK.  */ 


COUNTO.D  =  RESETN  6c  CYCENDN  &  (IVOTRDN  #  IVOTWRN)  & 
(COUNTO  $  HIGH); 

COUNTED  =  RESETN  &  CYCENDN  &  (IVOTRDN  #  IVOTWRN)  & 
(COUNT  1  $  COUNTO); 

COUNT2.D  =  RESETN  &  CYCENDN  &  (IVOTRDN  #  IVOTWRN)  & 
(COUNT2  $  (COUNT  1  &  COUNTO)); 

COUNT3.D  =  RESETN  &  CYCENDN  &  (IVOTRDN  #  IVOTWRN)  & 
(COUNT3  $  (COUNT2  &  COUNT1  &  COUNTO)); 

COUNTO.  OE=HIGH; 

COUNT  l.OE  =  HIGH; 

C0UNT2.0E  =  HIGH; 

C0UNT3.0E  =  HIGH; 

COUNTO.  AR  =  LOW; 

COUNT  1 .  AR  =  LOW ; 

COUNT2.AR  =  LOW; 

COUNT3.AR  =  LOW; 

COUNTO. SP  =  LOW; 

COUNT  1  .SP  =  LOW ; 

COUNT2.SP  =  LOW; 

COUNT3.SP  =  LOW; 

FIELD  CNTR  =  [COUNT3,  COUNT2,  COUNT  1,  COUNTO]; 
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/* 

/* 

/* 

/* 


CYCLE  END  SIGNAL 


*/ 
*/ 
*/ 
*/ 
*/ 


/*  THE  PURPOSE  OF  THE  CYCLE  END  SIGNAL  IS  TO  SIGNAL  THE  END 
/*  OF  THE  OF  THE  CURRENT  BUS  CYCLE  IN  ORDER  TO  RESET 
/*  THE  COUNTER.  THIS  RESETS  ITSELF  BY  INCLUDING  A  REFERENCE*/ 
/*TO  ITSELF  IN  THE  EQUATIONS.  */ 


CYCENDN.D  =  !(RESETN  &  CYCENDN  &  ( 

(IRAMCSN  &  (CNTR  :  HD)  &  IVOTRDN  &  VOTBURSTN) 

#  (IRAMCSN  &  (CNTR  :  H’6)  &  IVOTRDN  &  ! VOTBURSTN) 

#  (IRAMCSN  &  (CNTR  :  HD)  &  IVOTWRN) 

#  (IEPROMCSN  &  (CNTR  :  H’l)  &  IVOTRDN  &  VOTBURSTN) 

#  (IEPROMCSN  &  (CNTR  :  H7)  &  IVOTRDN  &  ! VOTBURSTN) 

#  (IUARTCSN  &  (CNTR  :  HD)  &  VOTBURSTN) 

#  (ITIMERCSN  &  (CNTR  :  HD)  &  VOTBURSTN) 

#  (IINTCSN  &  (CNTR  :  HD)  &  VOTBURSTN) 

#  (CNTR :  HF) 

)); 

CYCENDN.  AR  =  LOW; 

CYCENDN.SP  =  LOW; 


/* 


*/ 


/*  READ  CLOCK  ENABLE  */ 

/*  */ 

/*  THE  READ  CLOCK  ENABLE  SIGNAL  IS  USED  BY  THE  CPU  TO  */ 

/*  STROBE  DATA  OFF  THE  DATA  BUS  INTO  ITS  READ  BUFFER.  THIS  */ 
/*  SIGNAL  IS  STROBED  ONE  TIME  FOR  SINGLE  READS  AND  FOUR  */ 

/*  TIMES  FOR  QUAD  READS .  ONLY  RAM  AND  EPROM  MEMORY  */ 

/*USE  THE  QUAD  WORD  READS.  */ 


RDCENN.D  =  !(RESETN  &  CYCENDN  &  IVOTRDN  &  ( 

(IRAMCSN  &  ( 

(CNTR  :  HD) 

#  (I VOTBURSTN  &  (CNTR :  H2)) 
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#  (1V0TBURSTN  &  (CNTR  :  H’4)) 

#  (1VOTBURSTN  &  (CNTR  :  H’6)) 

) 

) 

#  (IEPROMCSN  &  ( 

(CNTR  :  H’l) 

#  (IVOTBURSTN  &  (CNTR  :  H3)) 

#  (!VOTBURSTN  &  (CNTR  :  H’5)) 

#  (IVOTBURSTN  &  (CNTR  :  H7)) 

) 

) 

#  (IUARTCSN  &  (CNTR  :  HD)) 

#  (ITIMERCSN  &  (CNTR  :  HD)) 

#  (IINTCSN  &  (CNTR  :  HD)) 

)); 

RDCENN.AR  =  LOW; 

RDCENN.SP  =  LOW; 


/*  */ 

/*  ACKNOWLEDGE  */ 

/*  */ 
/*  THE  ACKNOWLEDGE  SIGNAL  IS  USED  BY  THE  MEMORY  SYSTEM  */ 
/*  TO  LET  THE  CPU  KNOW  THAT  IT  HAS  PROCESSED  THE  WRITE  */ 

/*  CYCLE  SUFFICIENTLY  AND  THE  CPU  MAY  MOVE  ON  TO  THE  */ 

/*  NEXT  CYCLE.  THIS  SIGNAL  IS  GENERATED  IMPLICITLY  ON  */ 

/*  SINGLE  DATUM  READS  AND  NO  SOONER  THAN  FOUR  CLOCKS  */ 

/*  BEFORE  THE  END  OF  THE  LAST  READ  FOR  BURSTS.  */ 


j*  ******************************************************** *********/ 


ACKN.D  =  !(RESETN  &  CYCENDN  &  ( 

(1RAMCSN  &  1VOTWRN  &  (CNTR  :  HD)) 

#  (IRAMCSN  &  1VOTRDN  &  1VOTBURSTN  &  (CNTR  :  H3)) 

#  (IEPROMCSN  &  !VOTRDN  &  IVOTBURSTN  &  (CNTR  :  H’4)) 

#  (IUARTCSN  &  1VOTWRN  &  VOTBURSTN  &  (CNTR  :  HD)) 

#  (ITIMERCSN  &  1VOTWRN  &  (CNTR  :  HD)) 

#  (1INTCSN  &  1VOTWRN  &  (CNTR  :  HD)) 

) 


ACKN.AR  =  LOW; 
ACKN.SP  =  LOW; 
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/***********************  ******************************  **************/ 


/*  CHANGE  MADE  IN  THIS  SECTION  */ 

/*  BUS  ERROR  *1 

/*  */ 

/*  THE  BUS  ERROR  SIGNAL  IS  USED  BY  THE  PROCESSOR  TO  END  */ 
/*  A  BUS  CYCLE  THAT  TRIES  TO  ACCESS  AN  ADDRESS  THAT  IS  */ 

/*  NOT  POPULATED  IN  THE  MEMORY  SPACE.  */ 

/*  */ 

/*  CHANGED  COUNTER  FROM  H'F  TO  H’E'.  */ 


/*  *****************************************************************/ 

BUSERRN.D  =  !(RESETN  &  CYCENDN  &  (CNTR  :  ’HE)); 

BUSERRN.AR  =  LOW; 

BUSERRN.SP  =  LOW; 


I*  ^:^5{c5jc^ 5}:*^***^:**^:^*^ *************  ************  **********************/ 


/*  */ 

/*  VOTER  INTERRUPT  SIGNAL 

/* 

/*  THE  VOTER  INTERRUPT  SIGNAL  INFORMS  THE  CPU  WHEN 
/*  A  MISCOMPARE  HAPPENS  IN  ONE  OF  THE  FPGAS.  THE  SIGNAL  IS 
/*  HELD  UNTIL  A INTCSN  IS  GENERATED  BY  THE  ADDRESS 
/^DECODER. 


*/ 

*/ 

*/ 

*/ 

*/ 

*/ 


/*  *****************************************************************/ 


VOTINTN.D  =  !((AVOTERR  #  CVOTERR  #  DVOTERR  #  !  VOTINTN)  &  INTCSN); 
VOTINTN.AR  =  LOW; 

VOTINTN.SP  =  LOW; 


ATF22V 10C-5JC 

DIP. 10 0/24/W. 300/Ll. 175 


Figure  A.l  MEMCONT  PLD 
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ATF22V 10C-5JC 

DIP. 10 0/24 /W.  300/Ll. 175 


Figure  A.2  MEMENABLE  PLD 
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APPENDIX  B  TMR  SYSTEM  CONTROLLER  FILES 


This  appendix  contains  the  HDL  code  for  the  TMR  system  controller  FPGA. 


Table  B.  1.  Lists  the  state  machines  in  this  appendix  and  the  page  they  appear  on. 


File  and  Description 

Page  Number 

File  :  UARTC.V  1 

104 

File:  VOTMACH.V 

109 

File:  CONTROLLER. V 

112 

File:  COLLCT.V 

124 

File:  MODECNTRL.V 

126 

Table  B.l.  TMR  Files 
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//  Author:  Damen  Hofheinz 
//  UARTC.v 

//  created:  08/16/00  21:30:48 
//  INPUTS:  CLK 

//  OUTPUTS:  CUARTCSN,  UARTEN,  CUWREN,  CTRLDATAU[7:0] 
//  CTRLADDR[2:0] 

//  INTERNAL  SIGNALS: 


module  Uartc  (CLK,  CTRLADDR,  CTRLDATAU,  CUARTCSN,  CUWREN, 
UARTEN); 

input  CLK; 

output  [2:0] CTRLADDR; 
output  [7:0]  CTRLD AT AU ; 
output  CUARTCSN; 
output  CUWREN; 
output  UARTEN; 

reg  [2:0]CTRLADDR,  next_CTRLADDR; 
reg  [7:0]  CTRLD  AT  AU ,  next_CTRLDATAU; 
reg  CUARTCSN,  next_CUARTCSN ; 
reg  CUWREN,  next_CUWREN; 
reg  UARTEN,  next_UARTEN; 


//  USER  DEFINED  ENCODED  state  machine:  UARTC 
parameter  SO  =  51)00000, 

51=51)00001, 

S10  =  51)01010, 

51  1  =51)01011, 

512  =  51)01100, 

513  =  51)01101, 

514  =  51)01 110, 

515  =  51)01111, 

516  =  51)10000, 

517  =  51)10001, 

52  =  51)00010, 

S2a  =  51)10010, 
s3  =  51)00011, 

54  =  51)00100, 

55  =  51)00101, 

56  =  51)001 10, 

57  =  51)001 11, 

58  =  51)01000, 
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S9  =  51)01001; 

reg  [4:0]CurrState_Sreg0,  NextState_SregO; 

//Diagram  actions  (continuous  assignments  allowed  only:  assign  ...) 
//diagram  ACTIONS; 

//  Machine:  SregO 

//  NextState  logic  (combinatorial) 
always  @  (CurrState_SregO) 
begin 

case  (CurrState_SregO)  //  synopsys  parallel_case  full_case 
SO: 
begin 

begin 

NextState_SregO  =  S 1 ; 

end 

end 

SI: 

begin 

begin 

NextState_SregO  =  S2; 
next_CUWREN  =  1; 
next_CUARTCSN  =  0; 
next_UARTEN  =  0; 
end 

end 

S10: 

begin 

begin 

NextState_SregO  =  S 1 1 ; 
next.CUWREN  =  0; 

end 
end 
SI  1: 
begin 

begin 

NextState_SregO  =  SI  2; 
next_CUWREN  =  1; 

end 

end 

S12: 

begin 

begin 


105 


NextState_SregO  =  S13; 
next_CTRLADDR  =  31)001; 
next_CTRLD  AT  AU  =  81)00000000; 

end 

end 

S13: 

begin 

begin 

NextState_SregO  =  S 14; 
next_CUWREN  =  0; 

end 

end 

S14: 

begin 

begin 

NextState_SregO  =  S15; 
next_CUWREN  =  1 ; 

end 

end 

S15: 

begin 

begin 

NextState_SregO  =  SI  6; 
next_CUARTCSN  =  1; 
next_UARTEN  =  1 ; 

end 

end 

S16: 

begin 

begin 

NextState_SregO  =  S17; 
end 

end 

S17: 

begin 

begin 

NextState_SregO  =  S17; 

end 

end 

S2: 

begin 

next_CTRLADDR  =  31)01 0; 
next_CTRLD  AT  AU  =  81)10000000; 
begin 
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NextState_SregO  =  S2a; 

end 

end 

S2a: 

begin 

next_CUWREN  =  0; 

begin 

NextState_SregO  =  s3; 

end 

end 

s3: 

begin 

begin 

NextState_SregO  =  S4; 
next_CTRLADDR  =  3b011; 
next_CTRLD  AT  AU  =  8b  11000001; 
next_CUWREN  =  1; 

end 

end 

S4: 

begin 

begin 

NextState_SregO  =  S5; 
next_CUWREN  =  0; 

end 

end 

S5: 

begin 

begin 

NextState_SregO  =  S6; 
next.CUWREN  =  1; 

end 

end 

S6: 

begin 

begin 

NextState_SregO  =  S7; 
next_CTRLADDR  =  3bl00; 
next_CTRLD  AT  AU  =  8bl  1000100; 

end 

end 

S7: 

begin 

begin 
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NextState_SregO  =  S8; 
next_CUWREN=  1; 

end 

end 

S8: 

begin 

begin 

NextState_SregO  =  S9; 
next_CUWREN  =  0; 
end 
end 
S9: 
begin 

begin 

NextState_SregO  =  S10; 
next_CTRLADDR  =  3b000; 
next_CTRLDATAU  =  8b01001000; 
end 

end 

endcase 

end 

//  Current  State  Logic  (sequential) 
always  @  (posedge  CLK) 
begin 

CurrState_SregO  <=  NextState_SregO; 

end 

//  Registered  outputs  logic 
always  @  (posedge  CLK) 
begin 

CUWREN  <=  next_CUWREN ; 

CUARTCSN  <=  next_CUARTCSN; 

UARTEN  <=  next_UARTEN; 

CTRLADDR  <=  next_CTRLADDR; 

CTRLDATAU  <=  next_CTRLD AT AU ; 

end 

endmodule 
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//  Author:  Damen  Hofheinz 

//  File:  votmch.v 

//  created:  08/12/00  21:44:07 

//  INPUTS:  CLK,  CUARTINT,  CPUDONE,  INTCSN 

//  OUTPUTS:  UARTINT,  INTRCNTR[3:0] 

//  INTERNAL  SIGNALS:  NONE 

module  votmch  (CLK,  CPUDONE,  CUARTINT,  INTCSN,  INTRCNT, 
UARTINT); 

input  CLK; 
input  CPUDONE; 
input  CUARTINT; 
input  INTCSN; 
output  [3:0]INTRCNT; 
output  UARTINT; 

reg  [3:0]INTRCNT,  nextJNTRCNT; 
reg  UARTINT,  next_UARTINT; 


//  USER  DEFINED  ENCODED  state  machine:  SregO 
parameter  SI  =  21)00, 

52  =  21)01, 

53  =  21)10, 

54  =  21)11; 

reg  [l:0]CurrState_Sreg0,  NextState_SregO; 

//  Diagram  actions  (continuous  assignments  allowed  only:  assign  ...) 
//diagram  ACTIONS; 

//  Machine:  SregO 

//  NextState  logic  (combinatorial) 

always  @  (CPUDONE  or  CUARTINT  or  INTCSN  or  CurrState_SregO) 
begin 

case  (CurrState_SregO)  //  synopsys  parallel_case  full_case 
SI: 
begin 

if  (!  INTCSN) 
begin 

NextState_SregO  =  S2; 
end 

else  if  (CUARTINT  &&  ! INTRCNT) 
begin 
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NextState_SregO  =  S4; 


end 

else  if  (INTRCNT) 
begin 

NextState_SregO  =  S3; 
end 
end 
S2: 
begin 

if  (INTCSN) 
begin 

NextState_SregO  =  S 1 ; 

nextJNTRCNT  =  INTRCNT+1 ; 
end 
end 
S3: 
begin 

if  (CPUDONE) 
begin 

NextState_SregO  =  S 1 ; 

nextJNTRCNT  =  INTRCNT- 1 ; 
end 
end 
S4: 
begin 

next_UARTINT  =  1; 
if  (1CUARTINT) 
begin 

NextState_SregO  =  S 1 ; 

next_UARTINT  =  0; 
end 
end 

endcase 

end 

//  Current  State  Logic  (sequential) 
always  @  (posedge  CLK) 
begin 

CurrState_SregO  <=  NextState_SregO; 

end 

//  Registered  outputs  logic 
always  @  (posedge  CLK) 
begin 
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INTRCNT  <=  next_INTRCNT; 
UARTINT  <=  next_UARTINT; 
end 

endmodule 
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//  Author:  Damen  Hofheinz 
//  cntroller.v 

//  created:  08/12/00  21:34:37 
//  INPUTS:  SYSCLK,  INTCNTR[3:0] 

//OUTPUTS:  PROCXFER,  FIFOCTRLA[9:0],  FIFOCTRLB[9:0], 

//FIFOCTRLC[9:0],  FWRCLK1,  HDREN,  CTRLDATAV[7:0],  CUWREN, 
//CUARTCSN,  CUARTADSN,  CTRLADDR[2:0]  XFERCOMP 
//INTERNAL  SIGNALS:  FIFOENGA,  FIFOENGB,  FIFOENGC, 
//FIFOCOMP,  FIFOHDR[7:0],  CPUHDR[1:0],  HDONE,  BYTCNT[7:0] 
//CPUCNT[1:0] 


module  cntroller  (CTRLADDR,  CTRLDATAV,  CUARTADSN,  CUARTCSN, 
CURDEN,  FIFOCTRLA,  FIFOCTRLB,  FIFOCTRLC,  FWRCLK1,  HDREN,  ENTCNTR, 
PROCXFER,  SYSCLK,  XFERCOMP); 
input  [3:0]INTCNTR; 
input  SYSCLK; 
output  [2:0] CTRLADDR; 
output  [7:0] CTRLDATAV; 
output  CUARTADSN; 
output  CUARTCSN; 
output  CURDEN; 
output  [9:0]FIFOCTRLA; 
output  [9:0]FEFOCTRLB; 
output  [9:0]FIFOCTRLC; 
output  FWRCLK1; 
output  HDREN; 
output  PROCXFER; 
output  XFERCOMP; 

reg  [2:0] CTRLADDR,  next.CTRLADDR; 
reg  [7:0]CTRLDATAV,  next_CTRLD  AT  A  V ; 
reg  CUARTADSN,  next_CUARTADSN; 
reg  CUARTCSN,  next_CU  ART  CSN ; 
reg  CURDEN,  next_CURDEN; 
reg  [9:0]FIFOCTRLA,  next_FIFOCTRLA; 
reg  [9:0]FIFOCTRLB,  next_FIFOCTRLB ; 
reg  [9:0]FIFOCTRLC,  next_FEFOCTRLC; 
reg  FWRCLK1 ,  next_FWRCLKl ; 
reg  HDREN,  nextJHDREN; 
reg  PROCXFER,  next_PROCXFER ; 
reg  XFERCOMP,  next_XFERCOMP; 

//  diagram  signal  declarations 
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reg  [7:0]BYTCNT,  next_BYTCNT; 
reg  [1:0]CPUCNT,  next_CPUCNT; 
reg  [1:0]CPUHDR,  next_CPUHDR; 
reg  FFOCOMP,  next_FIFOCOMP; 
reg  FFOENGA,  next.FFOENGA; 
reg  FFOENGB,  next_FFOENGB; 
reg  FFOENGC,  next_FFOENGC; 
reg  [7:0]FFOHDR,  next_FFOHDR; 
reg  HDONE,  next_HDONE; 

//  USER  DEFINED  ENCODED  state  machine:  SregO 
parameter  XFERP  =11)1, 

XFERSTRT  =  11)0; 
reg  CurrState_SregO,  NextState_SregO; 

//  USER  DEFINED  ENCODED  state  machine:  Sregl 
parameter  CPUA  =  31)001, 

CPUB  =  31)010, 

CPUC  =  31)011, 

DONE  =  31)100, 

STRT  =  31)000, 

WAITST  =  31)101; 

reg  [2:0]CurrState_Sregl,  NextState_Sregl; 

//  USER  DEFINED  ENCODED  state  machine:  Sreg2 
parameter  FIFOSTO  =  31)001, 

FIFOST1  =  31)010, 

FIFOST2  =  31)011, 

FIFOST3  =  31)100, 

FFOST4  =  31)101, 

FIFOSTART  =  31)000; 
reg  [2:0]CurrState_Sreg2,  NextState_Sreg2; 

//  USER  DEFINED  ENCODED  state  machine:  Sreg3 
parameter  BTYE5  =  41)01 10, 

BYTE10  =  41)1011, 

BYTE2  =  41)0001, 

BYTE3  =  41)0010, 

BYTE4  =  41)0100, 

BYTE6  =  41)01 11, 

BYTE7  =  41)1000, 

BYTE8  =41)1001, 

BYTE9  =  41)1010, 

BYTSTRT  =  41)0000, 
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SI  =  4bl  100; 

reg  [3:0]CurrState_Sreg3,  NextState_Sreg3; 

//  Machine:  VOTE 
//  NextState  logic  (combinatorial) 
always  @  (INfTCNTR  or  CurrState_SregO) 
begin 

case  (CurrState_SregO)  //  synopsys  parallel_case  full_case 
XFERP: 
begin 

if  (XFERCOMP) 
begin 

NextState_SregO  =  XFERSTRT; 
end 
end 

XFERSTRT: 

begin 

next_PROCXFER  =  0; 
if  (INTCNTR) 
begin 

NextState_SregO  =  XFERP; 
next_PROCXFER  =  1; 
end 

else  if  (!  INTCNTR) 
begin 

NextState_SregO  =  XFERSTRT; 

end 

end 

endcase 

end 

//  Current  State  Logic  (sequential) 
always  @  (posedge  SYSCLK) 
begin 

CurrState_SregO  <=  NextState_SregO; 
end 

//  Registered  outputs  logic 
always  @  (posedge  SYSCLK) 
begin 

PROCXFER  <=  next_PROCXFER; 
end 
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//  Machine:  CPU 

//  NextState  logic  (combinatorial) 

always  @  (INTCNTR  or  CurrState_Sregl) 

begin 

case  (CurrState_Sregl )  //  synopsys  parallel_case  full_case 

CPUA: 
begin 

if  (CPUCNT==2b01) 
begin 

NextState_Sregl  =  CPUB; 
next_CPUHDR[  1 :0]  =  2b01; 
next_FIFOENGB  =  1; 
next_FIFOENGA  =  0; 
end 
end 
CPUB: 
begin 

if  (CPUCNT==2blO) 
begin 

NextState_Sregl  =  CPUC; 
next_CPUHDR[  1 :0]  =  2b  10; 
nextJFIFOENGC  =  1 ; 
next_F!FOEN  GB  =  0; 
end 

end 

CPUC: 

begin 

if  (CPUCNT==2’bl  1) 
begin 

NextState_Sregl  =  DONE; 
next_FIFOENGC  =  0; 
next_XFERCOMP  =  1; 
end 
end 

DONE: 

begin 

begin 

NextState_Sregl  =  WAITST; 
end 
end 
STRT: 
begin 

next_CPUHDR[  1 :0]  =  2b  1 1 ; 
if  (PROCXFER==l) 
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begin 

NextState_Sregl  =  CPUA; 
nextJFIFOENGA  =  1; 
next_CPUHDR[  1 :0]  =  21)00; 
end 
end 

WAITST: 

begin 

begin 

NextState_Sregl  =  STRT; 
end 

end 

endcase 

end 


//  Current  State  Logic  (sequential) 
always  @  (posedge  SYSCLK) 
begin 

CurrState_Sregl  <=  NextState_Sregl; 

end 

//  Registered  outputs  logic 
always  @  (posedge  SYSCLK) 
begin 

XFERCOMP  <=  next_XFERCOMP; 
CPUHDR  <=  next_CPUHDR; 
FIFOENGB  <=  next.FIFOENGB; 
FIFOENGA  <=  next_FIFOENGA; 
FIFOENGC  <=  next_FIFOENGC; 

end 


//  Machine:  FIFOXFER 
//  NextState  logic  (combinatorial) 
always  @  (INTCNTR  or  CurrState_Sreg2) 
begin 

case  (CurrState_Sreg2)  //  synopsys  parallel_case  full_case 
FEFOSTO: 
begin 

if  (FIFOENGC==  1  &&  HDONE==  1  &&  FIFOCOMP) 
begin 

NextState_Sreg2  =  FIFOST1; 
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next_FIFOCTRLC  [9 : 0]  =10^1100111111; 
next_FIFOHDR  =  81)00000100; 

end 

else  if  (FIFOENGB==l  &&  HDONE==l  &&FIFOCOMP) 
begin 

NextState_Sreg2  =  F1FOST1; 
next_FIFOCTRLB  [9:0]  =  10b  1 1001 11111; 
next_FIFOHDR  =  8b00000100; 

end 

else  if  (FIFOENGA==l  &&  HDONE=l  &&  FIFOCOMP) 
begin 

NextState_Sreg2  =  FIFOST1; 
next_FIFOCTRLA[9 : 0]  =  lObl  1001 11111; 
next.FIFOHDR  =  8b00000100; 

end 

else  if  (FIFOCOMP!=l) 
begin 

NextState_Sreg2  =  FIFOSTO; 
next_FIFOHDR  =  8bl  1000000; 
end 
end 

FIFOST1: 

begin 

if  (FIFOENGA==l  &&  HDONE  &&  FIFOCOMP) 
begin 

NextState_Sreg2  =  FIFOST2; 
next_FIFOCTRLA[9:0]  =  lO’blll  1001  111; 
next_FDFOHDR  =  8b00001000; 
end 

else  if  (FIFOENGB==l  &&  HDONE  &&  FIFOCOMP) 
begin 

NextState_Sreg2  =  FIFOST2; 
next_FIFOCTRLB[9:0]  =  lO’blll  1001  111; 
nextJFIFOHDR  =  8b00001000; 
end 

else  if  (FIFOENGC==l  &&  HDONE  &&  FIFOCOMP) 
begin 

NextState_Sreg2  =  FIFOST2; 
next_FIFOCTRLC[9:0]  =  lObl  1 1 1001 1 1 1 ; 
next.FIFOHDR  =  8b00001000; 

end 

else  if  (FEFOCOMP!=l) 
begin 

NextState_Sreg2  =  FIFOST1 ; 
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next_FIFOHDR  =  8b00000100; 
end 
end 

FIFOST2: 

begin 

if  (FIFOENGA==l  &&  HDONE  &&  FIFOCOMP) 
begin 

NextState_Sreg2  =  FIFOST3; 
next_FIFOCTRLA[9:0]  =  101)1 1 1 1 1 1001 1 ; 
next_FIFOHDR  =  81)00001 100; 
end 

else  if  (FTFOENGB==l  &&  HDONE  &&  FIFOCOMP) 
begin 

NextState_Sreg2  =  FEFOST3; 
nextJFTFOCTRLB  [9:0]  =  101)1 1 1 1 1 1001 1 ; 
next_FIFOHDR  =  81)00001 100; 
end 

else  if  (FIFOENGC==l  &&  HDONE  &&  FIFOCOMP) 
begin 

NextState_Sreg2  =  FIFOST3; 
next_FIFOCTRLC[9:0]  =  101)1 1111 10011; 
next.  .FIFOHDR  =  81)00001 100; 
end 

else  if  (FIFOCOMP  !=1) 
begin 

NextState_Sreg2  =  FEFOST2; 
next_FIFOHDR  =  81)00001000; 
end 
end 

FIFOST3: 

begin 

if  (FIFOENGC==  1  &&  HDONE  &&  FIFOCOMP) 
begin 

NextState_Sreg2  =  FIFOST4; 
next JFIFOCTRLC  [9:0]  =  101)1 111111 100; 
next_CPUCNT  =  CPUCNT+1 ; 
end 

else  if  (FIFOENGA==l  &&  HDONE  &  FIFOCOMP) 
begin 

NextState_Sreg2  =  FIFOST4; 
next_FIFOCTRLA[9:0]  =  1  Obi  1 1 1 1 1 1 100; 
next_CPUCNT  =  CPUCNT+1 ; 
end 

else  if  (FIFOENGB==l  &&  HDONE  &&  FIFOCOMP) 
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begin 


NextState_Sreg2  =  FIF0ST4; 
next_FIFOCTRLB  [9:0]  =  lObl 111111 100; 
next_CPUCNT  =  CPUCNT+1; 
end 

else  if  (FDF0C0MP!=1) 
begin 

NextState_Sreg2  =  FEF0ST3; 
nextJFIFOHDR  =  8b00001 100; 
end 
end 

FEF0ST4: 

begin 

if  (CPUCNT==2b  1 1  &&  FIFOCOMP==  1 ) 
begin 

NextState_Sreg2  =  FIFOSTART; 
end 

else  if  (CPUCNT!=2bl  1  &&  FIFOCOMP==l) 
begin 

NextState_Sreg2  =  FIFOSTART; 
end 
end 

FIFOSTART: 

begin 

if  (FEFOENGC==l  &&  HDONE) 
begin 

NextState_Sreg2  =  FIFOSTO; 
next_FIFOCTRLC  [9:0]  =  lObOOl  1111111; 
next_FEFOHDR  =  8b  1 1000000; 
end 

else  if  (FIFOENGA==l  &&  HDONE) 
begin 

NextState_Sreg2  =  FIFOSTO; 
next_FIFOCTRLA[9 : 0]  =  lObOOl  1111111; 
next_FIFOHDR  =  8bl  1000000; 
end 

else  if  (FIFOENGB==l  &&  HDONE) 
begin 

NextState_Sreg2  =  FIFOSTO; 
next_FIFOCTRLB  [9 : 0]  =  lObOOl  1111111; 
next_FTFOHDR  =  8bl  1000000; 
end 
end 

endcase 
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end 


//  Current  State  Logic  (sequential) 
always  @  (posedge  SYSCLK) 
begin 

CurrState_Sreg2  <=  NextState_Sreg2; 

end 

//  Registered  outputs  logic 
always  @  (posedge  SYSCLK) 
begin 

FIFOCTRLC  <=  next_FEFOCTRLC; 

FIFOCTRLB  <=  next_FIFOCTRLB ; 

FEFOCTRLA  <=  next_FIFOCTRLA; 

FEFOHDR  <=  nextJFIFOHDR; 

CPUCNT  <=  next_CPUCNT; 

end 

//  Machine:  BYTE 
//  NextState  logic  (combinatorial) 
always  @  (INTCNTR  or  CurrState_Sreg3) 
begin 

case  (CurrState_Sreg3)  //  synopsys  parallel_case  full_case 
BTYE5: 
begin 

begin 

NextState_Sreg3  =  BYTE6; 
next_FWRCLKl  =  0; 
next_HDREN  =  0; 
next_HDONE  =  1 ; 
end 
end 

BYTE10: 

begin 

begin 

NextState_Sreg3  =  BYTE7; 
next_BYTCNT  =  BYTCNT+1 ; 
next_FWRCLKl  =  0; 
end 
end 

BYTE2: 

begin 

next_CUARTCSN  =  1 ; 
next_CTRLADDR[2:0]  =  3h000; 
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begin 

NextState_Sreg3  =  BYTE3; 
end 
end 

BYTE3: 

begin 

next_CUARTADSN  =  1; 
begin 

NextState_Sreg3  =  BYTE4; 
next.CTRLDATAV  =  CPUHDRIFIFOHDR; 
next_HDREN  =  1; 
next_FWRCLKl  =  0; 

end 

end 

BYTE4: 

begin 

next_CURDEN  =  1 ; 
nextJFWRCLKl  =  1; 
begin 

NextState_Sreg3  =  BTYE5; 
next_BYTCNT=  1; 

end 

end 

BYTE6: 

begin 

begin 

NextState_Sreg3  =  BYTE7; 
next_FIFOCOMP  =  0; 

end 

end 

BYTE7: 

begin 

next_FWRCLKl  =  1; 
next_HDONE  =  0; 
begin 

NextState_Sreg3  =  BYTE8; 
end 
end 

BYTE8: 

begin 

begin 

NextState_Sreg3  =  BYTE9; 
next_BYTCNT  =  BYTCNT+1; 
next_FWRCLKl  =  0; 
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end 


end 

BYTE9: 

begin 

if  (BYTCNT==8’b01010010) 
begin 

NextState_Sreg3  =  S 1 ; 
next_FIFOCOMP  =  1; 
next_FWRCLKl  =  1; 
end 

else  if  (BYTCNT<8’b01010010) 
begin 

NextState_Sreg3  =  BYTE  10; 
next.FWRCLKl  =  1; 
end 

end 

BYTSTRT: 

begin 

next_CUARTCSN  =  0; 
next_CUARTADSN  =  0; 
next_CURDEN  =  0; 

if  (FIFOENGAIIFIFOENGB1IFIFOENGC) 
begin 

NextState_Sreg3  =  BYTE2; 
next_BYTCNT  =  0; 
end 

end 

SI: 

begin 

begin 

NextState_Sreg3  =  BYTSTRT; 
end 
end 

endcase 

end 

//  Current  State  Logic  (sequential) 
always  @  (posedge  SYSCLK) 
begin 

CurrState_Sreg3  <=  NextState_Sreg3; 

end 

//  Registered  outputs  logic 
always  @  (posedge  SYSCLK) 
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FWRCLK1  <=  nextJFWRCLKl; 
HDREN  <=  next_HDREN; 

CUARTCSN  <=  next_CU  ARTCSN ; 
CTRLADDR  <=  next.CTRLADDR; 
CUARTADSN  <=  next_CUARTADSN; 
CTRLDATAV  <=  next_CTRLDATAV ; 
CURDEN  <=  next_CURDEN; 

HDONE  <=  next.HDONE; 

BYTCNT  <=  next_BYTCNT; 
FIFOCOMP  <=  next_FIFOCOMP; 


//  Author:  Damen  Hofheinz 
//  File:  ColIct.v 
//  created:  08/12/00  21:37:16 
//  INPUTS:  CLK,  VOTINT 

//  OUTPUTS:  FIFOCTRLA,  FIFOCTRLB,  FIFOCTRLC 
//  INTERNAL  SIGNALS:  COLCNT[7:0] 

// 

module  Collet  (CLK,  FIFOCTRLA,  FIFOCTRLB,  FIFOCTRLC,  VOTINT); 

input  CLK; 

input  VOTINT; 

output  FIFOCTRLA; 

output  FIFOCTRLB; 

output  FIFOCTRLC; 

reg  FIFOCTRLA; 
reg  FIFOCTRLB; 
reg  FIFOCTRLC; 

//  diagram  signal  declarations 
reg  [7:0]COLCNT,  next_COLCNT; 

//  USER  DEFINED  ENCODED  state  machine:  COLLECT 
parameter  S 1  =  21)00, 

S2  =  21)01, 

83  =  21)10, 

S4  =  21)11; 

reg  [l:0]CurrState_Sreg0,  NextState_SregO; 

//  Diagram  actions  (continuous  assignments  allowed  only:  assign  ...) 
//diagram  ACTIONS; 

//  Machine:  SregO 

//  NextState  logic  (combinatorial) 
always  @  (VOTINT  or  CurrState_SregO) 
begin 

case  (CurrState_SregO)  //  synopsys  parallel_case  full_case 
SI: 
begin 

if  (!  VOTINT) 
begin 

NextState_SregO  =  S2; 

end 

end 


124 


S2: 

begin 

begin 

NextState_SregO  =  S3; 
FIF0CTRLA=1; 
FIF0CTRLB=1; 
FIF0CTRLC=1; 
next_COLCNT  =  0; 
end 

end 

S3: 

begin 

next.COLCNT  =  COLCNT+1 ; 
if  (COLCNT==8  b  1 0 1 00 1 00) 
begin 

NextState_SregO  =  S4; 
end 
end 
S4: 
begin 

begin 

NextState_SregO  =  S 1 ; 
FIFOCTRLA=0; 
FEFOCTRLB=0; 
FIFOCTRLC=0; 
end 

end 

endcase 

end 

//  Current  State  Logic  (sequential) 
always  @  (posedge  CLK) 
begin 

CurrState_SregO  <=  NextState_SregO; 

end 

//  Registered  outputs  logic 
always  @  (posedge  CLK) 
begin 

COLCNT  <=  next_COLCNT; 

end 

endmodule 
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//  Author:  Damen  Hofheinz 
//  File:  MODECNTRL.v 
//  created:  08/15/00  17:33:14 
//  INPUTS:  UARTINT,  CLK,  AIN[7:0] 

//  OUTPUTS:  CUARTADSN,  FORCE,  INO,  CTRLADDR[2:0],  CURDENN, 
//CUARTCSN,  MDCTRL[7:0] 

//  INTERNAL  SIGNALS:  NONE 


module  rdmach  (AIN,  BRDRST,  CLK,  CTRLADDR,  CUARTADSN, 
CUARTCSN,  CURDENN,  FORCE,  INO,  MDCTRL,  SYSRST,  UARTINT); 
input  [7:0] AIN; 
input  CLK; 
input  UARTINT; 
output  BRDRST; 
output  [2:0] CTRLADDR; 
output  CUARTADSN; 
output  CUARTCSN; 
output  CURDENN; 
output  FORCE; 
output  INO; 
output  [7:0]MDCTRL; 
output  SYSRST; 

reg  BRDRST; 

reg  [2:0]  CTRLADDR; 

reg  CUARTADSN,  next_CUARTADSN; 

reg  CUARTCSN; 

reg  CURDENN; 

reg  FORCE; 

reg  INO; 

reg  [7:0] MDCTRL,  next_MDCTRL; 
reg  SYSRST; 


//  SYMBOLIC  ENCODED  state  machine:  SregO 
parameter  S 1  =  41)0000, 

810  =  41)0001, 

52  =  41)0010, 

53  =  41)0011, 

54  =  41)0100, 

55  =  41)0101, 

56  =  41)0110, 

57  =  41)01 11, 
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S8  =  41)1000, 

89  =  41)1001; 

reg  [3:0]CurrState_Sreg0,  NextState_SregO; 


//  Machine;  MODECNTRL 

//  NextState  logic  (combinatorial) 

always  @  (AIN  or  UARTINT  or  CurrState_SregO) 

begin 

case  (CurrState_SregO)  //  synopsys  parallel_case  full_case 
SI: 
begin 

if  (UARTINT) 
begin 

NextState_SregO  =  S2; 

CUARTCSN=1; 

INO=l; 

FORCE=0; 

SYSRST=0; 

BRDRST=0; 

end 

end 

S10: 

begin 

FORCE=l; 

end 

S2: 

begin 

begin 

NextState_SregO  =  S3; 
CTRLADDR[2:0]=3B010; 

end 

end 

S3: 

begin 

begin 

NextState_SregO  =  S4; 
next_CUARTADSN  =  1; 

end 

end 

S4: 

begin 

begin 

NextState_SregO  =  S5; 
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end 


CURDENN=1; 


end 

S5: 

begin 

begin 

NextState_SregO  =  S6; 
next_MDCTRL[7 :0]  =  AIN; 
end 
end 
S6: 
begin 

begin 

NextState_SregO  =  SI; 

CURDENN=0; 

CUARTCSN=0; 

INO=0; 

end 

end 

S7: 

begin 

if  (MDCTRL[0]) 
begin 

NextState_SregO  =  S10; 

end 

else  if  (MDCTRL[2]) 
begin 

NextState_SregO  =  S8; 
end 

else  if  (MDCTRL[1]) 
begin 

NextState_SregO  =  S9; 
end 

end 

S8: 

begin 

BRDRST=1; 

end 

S9: 

begin 

SYSRST=1; 

end 

endcase 

end 
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//  Current  State  Logic  (sequential) 
always  @  (posedge  CLK) 
begin 

CurrState_SregO  <=  NextState_SregO; 
end 

//  Registered  outputs  logic 
always  @  (posedge  CLK) 
begin 

CUARTADSN  <=  next_CUART  ADSN; 
MDCTRL  <=  next_MDCTRL; 
end 

endmodule 
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APPENDIX  C  PROGRAM  FILES 


This  Appendix  lists  the  Makefile  and  program  files  utilized  with  the  Generic 


Cross  Compiler  provided  by  IDT. 


^  ^  ^  ^  ^  ^  v|^  ^  ^  ^  ^  ^  ^  ^  ^1  ^  ^  ^  ^  ^  ^  j|>  ^  ^  ^  jJj  jjj*  ^  ^  aJa  j 


/*  Name:  makefile  */ 

/*Written  by:  Damen  Hofheinz  */ 

/*Date:  9/28/00  */ 

/*Name:  Makefile  */ 

/*Function:  This  file  is  utilized  by  the  GCC  compiler  to  assemble  and  link  the  */ 
/*  program  file.  */ 

/*  */ 


/* 


*/ 


/  vL  v].  vi*  ^  kU  J#  <in  jj*  vi^  •1'  4«  4*  4^  4*  4a  4*  4a  4a  4*  4*  4a  4*  “4*  4*  4a  4*  4*  4a  *4*  4*  4*  4f  4*  4*  4*  4?  4a  4*  ^  4*  4f  4*  4*  4*  *4*  4f  4*  ^  4?  4f  4f  4*  4a  4*  4-*  4^  4f  4?  4f  4?  / 


/*  NAME  OF  FILE  TO  ASSEMBLE  */ 

/*  DEFINES  DIRECTORY  OF  FILE  LOCATIONS  */ 


EXE=rom 

STARTUPDIR=/IDTC5. 1 
INCDIR=/IDTC5. 1 
LBBDIR=/IDTC5. 1 
0PTFLAGS=-02 

/*  DEFINES  NAME  OF  OBJECT  FILE  */ 

OBJS=  $(EXE).o 

/*  DEFINES  NAME  OF  MOTOROLA  S-RECORD  FILE  TO  MAKE*/ 
all:  $(EXE).sre 


/*  CONSTRUCTS  .SRE  FILE  */ 

$(EXE).sre:  $(EXE) 

objcopy  -O  srec  $(EXE)  $(EXE).sre 


/*  CREATES  .EXE  FILE  FROM  OBJECT  FILE  AND  LINKS  */ 
/*  TO  ADDR  0XBFC00000  */ 

$(EXE):  $(OBJS) 
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gcc  -W1.-M  -nostdlib  $(OPTFLAGS)  -L$(LffiDIR)  -o  $(EXE)  -Ttext  OxbfcOOOOO 
$(OBJS)  -lkil  -lc  -lm  -link  -lgcc  >  $(EXE).map 


/*  CREATES  OBJECT  FILE  FROM  ASSEMBLY  LANGUAGE  FILE  */ 
$(EXE).o:  $(EXE).S 

gcc  -nostdinc  $(OPTFLAGS)  -I$(INCDIR)  -c  -g  -O  -Wa,-alh  $(EXE).S  >  $(EXE).lst 


/*  OPTION  TO  DELETE  FILES  FROM  LAST  RUN  */ 

clean: 

del  *.o 

del  $(EXE).sre 
del  $(EXE) 
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^jjc  ******************************************************************/ 


/*Name:  rom.s  */ 

/♦Written  by:  Damen  Hofheinz  */ 

/*Date:  9/28/00  */ 

/*  */ 
/*Function:  This  program  initializes  the  DDT3081  processor  and  reads  program  */ 

/*  instructions  from  ROM.  The  program  then  writes  data  to  an  */ 

/*  address  location  in  the  KSEGO  memory  segment  that  is  */ 

/*  incremented  after  each  write.  */ 

/*  */ 


j  ^  ^  ?jc  5js  5|C  2>Jc  #jc  *Jc  ijC  5jC  5jC  5j£  rjC  ^|C  ?|C  5jC  jjc  ^JC  j|£  jjc  j 

/*  startup  code,  noncacheable,  no  exceptions 
*/ 

#include  "mips.li" 

#include  "machine.h" 

#include  "iregdef.h" 

#include  "idtcpu.h" 

#include  "idtmon.h" 


.text 

/*  defines  text  section 

*/ 

reset_exception: 

/*  aligns  instruction  to  reset  address 

*/ 

j  start 

/*  Upon  reset  program  jumps  to  start 

*/ 

.align  8 

.set  noreorder 

nop  ;  .set  reorder 

.align  7 

general_exception : 

/*  If  the  processor  has  a  general 

*/ 

j  -exit 

/*  exception  then  it  performs  a  jump  to 

*/ 

/*  the  _exit  label 

*/ 

.globl  start 

/*  global  declaration  of  the  label  start 

*/ 

.ent  start 

start: 

.set  noreorder 

/*  LOAD  SETUP  DATA  INTO  REGISTER  VO  */ 

/*  SETUP  DATA  IS  FORMED  BY  ORing  DEFINDED  */ 

/*  VARIABLE  IN  MIPS.H.  SETUP  IS:  CPO  USABLE  AND  IN  */ 
/*  KERNEL  MODE,  PROCESSOR  IN  BOOTSTRAP  */ 

/*  MODE  AND  CLEAR  INTR  MASKS.  */ 


li  vO,SR_PEISR_CUOISR_BEV 
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/*  LOAD  STATUS  REGISTER  WITH  SETUP  DATA  */ 

mtcO  vO,CO_SR 
nop 

/*  CLEAR  SOFTWARE  INTERRUPTS  */ 

/*  REQUIRED  NOPS  DUE  TO  REGISTER  */ 

/*  WRITE  INSTRUCTION  */ 

mtcO  zero,CO_CAUSE 
nop 
nop 

.set  reorder 


/*  LOAD  BEGINNING  ADDR  IN  TO  */ 

li  t0,0xa0001000 


/* 

/* 

/* 

/* 

lp: 

sw  zero,(tO) 
addu  t0,4 
and  t0,~0x2000 
b  lp 

/*  CONTINUOS  LOOP  IF  PROGRAM  EXPERIENCES  A  */ 
/*  GENERAL  EXCEPTION  */ 

_exit: 

b  _exit 

.end  start 


ROM  WRITE  LOOP  */ 

STORE  DATA  TO  ADDRESS  POINTED  TO  BY  */ 
REGISTER  TO.  ADD  4  TO  ADDRESS  STORED  IN  */ 
REGISTER  TO,  THEN  BRANCH  TO  LP.  */ 
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/*******************************************************************/ 


/*Name:  ramwrite.s  */ 

/*Writtenby:  Damen  Hofheinz  */ 

/*Date:  9/28/00  */ 

/*  */ 

/*Function:  This  program  initializes  the  EDT3081  processor,  reads  program  */ 

/*  instructions  from  ROM,  and  writes  to  RAM.  The  program  */ 

/*  writes  data  (Oxdeadbeef)  to  a  RAM  address  location  in  the  KSEG1  */ 

/*  memory  segment  that  is  incremented.  */ 

/*  */ 


/*  startup  code,  noncacheable,  no  exceptions  */ 
#include  "mips.h" 

#include  "machine.h" 

#include  "iregdef.h" 

#include  "idtcpu.h" 

#include  "idtmon.h" 

.text 

reset_exception: 

j  start 
.align  8 
.set  noreorder 
nop ;  .set  reorder 
.align  7 

general_exception : 
j  -exit 

.globl  start 
.ent  start 


start: 

.set  noreorder 

/*  LOAD  SETUP  DATA  INTO  REGISTER  VO  */ 

/*  SETUP  DATA  IS  FORMED  BY  ORing  DEFINDED  */ 

/*  VARIABLE  IN  MIPS.H.  SETUP  IS:  CPO  USABLE  AND  IN  */ 
/*  KERNEL  MODE,  PROCESSOR  IN  BOOTSTRAP  */ 

/*  MODE  AND  CLEAR  INTR  MASKS.  */ 


li  vO,SR_PEISR_CUOISR_BEV 
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/*  LOAD  STATUS  REGISTER  WITH  SETUP  DATA  */ 

mtcO  vO,CO_SR 
nop 

/*  CLEAR  SOFTWARE  INTERRUPTS  */ 

/*  REQUIRED  NOPS  DUE  TO  REGISTER  */ 

/*  WRITE  INSTRUCTION  */ 

mtcO  zero,CO_CAUSE 
nop 
nop 

.set  reorder 


/*  LOAD  BEGINNING  RAM  ADDRESS  */ 

/*  LOAD  DATA  IN  TEMPORARY  REGISTER  */ 

li  tO, 0x80000000 

li  tl,0xdeadbeef 


/*  RAM  WRITE  LOOP  */ 

/*  STORE  DATA  TO  ADDRESS  POINTED  TO  BY  */ 
/*  REGISTER  TO.  ADD  4  TO  ADDRESS  STORED  IN  */ 
/*  REGISTER  TO,  THEN  BRANCH  TO  LP.  */ 

P: 

sw  tl,(t0) 
addu  tO, 4 
and  tO, -0x6000 
b  lp 

exit: 

b  _exit 

.end  start 
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^*  ******************************************************************/ 


/*Name:  uart.s  / 

/*Written  by:  Damen  Hofheinz  */ 

/*Date:  10/29/00  */ 

/*  */ 

/*Function:  This  program  initializes  the  IDT308 1  processor,  reads  program  */ 

/*  instructions  from  ROM  which  initializes  the  UART.  The  program  */ 

/*  setups  the  UART  in  polling  mode,  8  bits,  no  parity,  9600  baud.  */ 

/*  A  continuous  loop  writes  data  to  the  UART  output  address  */ 

/*  that  outputs  ACSH  character  0x23  or  ‘#\  */ 

/*  */ 


/******************************************************************/ 

#include  "mips.h" 

#include  "machine.h" 

#include  "iregdef.h" 

#include  "idtcpu.h" 

#include  "idtmon.h" 

.text 

reset_exception: 

j  -exit 
.align  8 
.set  noreorder 
nop  ;  .set  reorder 
.align  7 

general_exception: 

.set  noreorder 
nop 

li  t0,0xfeedface 
nop 

.set  reorder 

j  IP 

.globl  start 
.ent  start 

start: 

.set  noreorder 

/*  LOAD  SETUP  DATA  INTO  REGISTER  VO  */ 

/*  SETUP  DATA  IS  FORMED  BY  ORing  DEFINDED  *1 
/*  VARIABLE  IN  MIPS.H.  SETUP  IS:  CP0  USABLE  AND  IN  */ 
/*  KERNEL  MODE,  PROCESSOR  IN  BOOTSTRAP  */ 

/*  MODE  AND  CLEAR  INTR  MASKS.  */ 
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li  vO,SR_PEISR_CUOISR_BEV 

/*  LOAD  STATUS  REGISTER  WITH  SETUP  DATA  */ 
mtcO  vO,CO_SR 
nop 

/*  CLEAR  SOFTWARE  INTERRUPTS  */ 

/*  REQUIRED  NOPS  DUE  TO  REGISTER  */ 

/*  WRITE  INSTRUCTION  */ 

mtcO  zero,CO_CAUSE 
nop 
nop 

.set  reorder 


/*FIFO  CONTROL  REGISTER*/ 
/*  ENABLE  FIFOs  */ 


li  tl,Oxclclclcl 

nop 

sw  tl,0xBFE00008 
nop 

/*  LINE  CONTROL  REGISTER  */ 

/*  SET  DLAB  TO  ONE  AND  DEFINE  WORD  LENGTH  AS  */ 
/*  8  BITS  */ 
li  tl, 0x83838383 

nop 

sw  1 1 ,0xBFE0000c 

nop 

/*  MODEM  CONTROL  REGISTER  */ 

/*  SET  UART  IN  POLLING  MODE  */ 
li  1 1,0x00000000 

nop 

sw  tl,0xBFE00010 
nop 

/*  DIVISOR  LATCH  LSB  REGISTER  */ 

/*  SET  LOWER  DIVISOR  TO  72  DECIMAL  */ 
li  1 1,0x48484848 

nop 

sw  tl,0xBFE00000 
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nop 


/*  DIVISOR  LATCH  USB  REGISTER 

*/ 

/*  CLEAR  DIVISOR  REGISTER 

*/ 

li 

tl,OxOOOOOOOO 

nop 

sw 

tl,OxBFE00004 

nop 

/*  LINE  CONTROL  REGISTER 

*/ 

/*  SET  DLAB  TO  ZERO  TO  ACCESS 

*/ 

/*RCV/TRANSMIT  REGISTERS 

*/ 

li 

tl, 0x03030303 

nop 

sw 

tl,OxBFEOOOOC 

nop 

/*  INTERRUPT  ENABLE  REGISTER 

*/ 

/*  DISABLE  INTERRUPTS 

*/ 

li 

tl, 0x00000000 

nop 

sw 

tl  ,0xBFE00004 

nop 

/*  WRITE  LOOP.  LOAD  DATA  INTO  REGISTER 

*/ 

/*  Tl.  STORE  DATA  (WRITE)  TO  UART  TRANSMIT 

*/ 

/*  REGISTER. 

*/ 

lp: 

li 

1 1,0x23222223 

nop 

sw 

tl,0xBFE00000 

nop 

nop 

b 

lp  /*  branch  back  to  lp  */ 

nop 

_exit: 

b 

_exit 

.end  start 

j  ^  jjc  sjc  ^  ^  ^  ^  ^  ^  ^  ^  ^  ^  ^  ^  <^|  ^  jJj  ^  jJj  ^  ^  ^  ^  ^  jJj  j|-  jjjj  ^J>  ^  ^ 

*/ 

/*Name: 

uartio.s 

*/ 

/^Written  by: 

Damen  Hofheinz 

*/ 

/*Date: 

11/05/00 

*/ 

139 


*/ 

/^Function:  This  program  initializes  the  IDT3081  processor,  reads  program  */ 
/*  instructions  from  ROM  which  initializes  the  UART.  The  program  */ 

/*  setups  the  UART  in  autoflow  mode,  8  bits,  no  parity,  9600  baud.  */ 

/*  A  loop  reads  in  data  from  the  UART,  adds  30  to  this  data  and  */ 

/*  ouputs  the  modified  data  to  the  UART.*/ 

*/ 


/***** ******************************************************* ******/ 


/*  startup  code,  noncacheable,  no  exceptions  */ 

#include  "mips.h" 

#include  "machine.h" 

#include  "iregdef.h" 

#include  "idtcpu.h" 

#include  "idtmon.h" 

.text 

reset_exception: 

j  start 

.align  8 
.set  noreorder 
nop  ;  .set  reorder 
.align  7 

general_exception: 

.set  noreorder 
nop 

li  t0,0xfeedface 

mfcO  v0,C0_CAUSE 
nop 

.set  reorder 

j  IP 

.globl  start 
.ent  start 

start: 

.set  noreorder 

/*  LOAD  SETUP  DATA  INTO  REGISTER  VO  */ 

/*  SETUP  DATA  IS  FORMED  BY  ORing  DEFINDED  */ 

/*  VARIABLE  IN  MIPS.H.  SETUP  IS:  CPO  USABLE  AND  IN  */ 
/*  KERNEL  MODE,  PROCESSOR  IN  BOOTSTRAP  */ 

/*  MODE  AND  CLEAR  INTR  MASKS.  */ 

li  vO,SR_PEISR_CUOISR_CU  1  ISR_BEVISR_IM  ASK8 
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/*  LOAD  STATUS  REGISTER  WITH  SETUP  DATA  */ 
mtcO  vO,CO_SR 
nop 

mtcO  zero,CO_CAUSE  /*  clear  software  interrupts  */ 

nop  /*  rqd  nops  */ 

nop 

.set  reorder 

/*FIFO  CONTROL  REGISTER*/ 

/*  ENABLE  FIFOs  */ 
li  tl,0xc7c7c7c7 
nop 

sw  1 1 ,0xBFE00008 

nop 

/*  LINE  CONTROL  REGISTER  */ 

/*  SET  DLAB  TO  ONE  AND  DEFINE  WORD  LENGTH  AS  */ 
/*  8  BITS  */ 

li  tl, 0x83838383 

nop 

sw  1 1 ,0xBFE0000c 

nop 

/*  MODEM  CONTROL  REGISTER  */ 

/*  SET  UART  IN  POLLING  MODE  */ 

li  tl, 0x23232323 

nop 

sw  tl,OxBFE00010 
nop 

/*  DIVISOR  LATCH  LSB  REGISTER  */ 

/*  SET  LOWER  DIVISOR  TO  72  DECIMAL  */ 
li  tl, 0x48484848 

nop 

s  w  1 1 ,0xBFE00000 

nop 

/*  DIVISOR  LATCH  USB  REGISTER  */ 

/*  CLEAR  DIVISOR  REGISTER  */ 

li  tl, 0x00000000 

nop 

sw  1 1 ,0xBFE00004 
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nop 


/*  LINE  CONTROL  REGISTER  */ 

/*  SET  DLAB  TO  ZERO  TO  ACCESS  */ 

/*RCV7TRANSMIT  REGISTERS  */ 

li  1 1,0x03030303 

nop 

sw  tl,0xBFE0000C 
nop 

/*  INTERRUPT  ENABLE  REGISTER  */ 

/*  DISABLE  INTERRUPTS  */ 

li  1 1,0x00000000 

nop 

sw  tl,0xBFE00004 
nop 

/*  OUTPUTS  START  CHARACTER  #  TO  SCREEN  */ 
lp: 

li  1 1,0x23222223 

nop 

li  t4, 0x00000060 

nop 

li  t5, 0x00000001 

nop 


/*  LOOP  TO  READ  IN  DATA,  ADD  30,  AND  OUTPUT  DATA  */ 


xt:  lw 

t2,0xBFE00014 

nop 

andi 

t2,t2, 0x00000060 

nop 

bne 

t2,t4,xt 

nop 

sw 

tl,0xBFE00000 

nop 

gt:  lw 

t3,0xBFE00014 

nop 

andi 

t3  ,t3 ,0x0000000 1 

nop 

bne 

t3,t5,gt 

nop 
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lw  t7,0xBFE00000 
nop 

li  t2,0xDEADBEEF 
nop 

lw  t2,0xBFE00014 
nop 

andi  t2,t2, 0x00000060 
nop 

bne  t2,t4,xt 
nop 

addi  t7,t7,32 
nop 

sw  t7,0xBFE00000 
nop 


nop 

b  lp  /*  branch  back  to  lp  */ 

nop 

exit: 

b  _exit 

.end  start 
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APPENDIX  D  PART  SELECTION 

The  following  tables  give  a  list  of  compatible  radiation  hardened  and  SEU  tested 
devices.  The  primary  purpose  of  these  tables  is  to  assist  in  part  selection  for  a  space 
flight  ready  TMR  design. 
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Table  D.2.  COTS  Device  List 
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Table  D.  1 .  Radiation  Hardened  Device  List 
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